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Bár szerkesztőségünk számára 

a 2004-es és is meglehetősen 
mozgalmas volt, olvasóink ebből 
viszonylag keveset érezhettek, 
hiszen az eddigi változások in- 
kább a színfalak mögött zajlottak. 
2005-ben terveink és reményeink 
szerint egy új korszak kezdődik a lap 
életében, melynek legfontosabb jel- 
lemzője a tartalomnak a felhasználói 
irányba való fokozatos eltolódása lesz. 
Szeretnénk új témákat, és új arcokat 
bemutatni a magyar linuxos közön- 
ségnek, illetve szeretnénk ennek 

a közösségnek valamiféle központi 
fórumává válni, valahogy úgy, ahogy 
egy-egy szaklap fóruma és elsődleges 
információforrása lehet a megfelelő 
tudományterületnek. 

A Linuxvilágot tehát mostantól nem- 
csak olvasni, írni is lehet! Bárkitől 
szívesen fogadunk a témához kap- 
csolódó, és közérdeklődésre számot 
tartó írásokat. lerveink szerint hama- 
rosan egy cikkírói pályázatot is meg- 
hirdetünk, amelynek nem titkolt cél- 
ja a ,vérfrissítés", és az új témák és 
lehetőségek felkutatása. 

És most lássuk, mit kínálunk az új 
esztendő első számában. 

E havi számunk talán legérdekesebb 
témája a videószerkesztés Linux alatt. 
Két cikk is foglalkozik ezzel a terület- 
tel. Marcel Gagné a maga jól ismert, 
egyedi stílusában teszi ezt, két orosz 
szerzőtől (Olexiy Iykhomyrov és 
Denis Tonkonog) pedig egészen ko- 
moly bevezetőt kapunk a Kino nevű 


alkalmazás használatába. Utóbbi 

cikk tulajdonképpen elegendő in- 
formációt tartalmaz ahhoz, hogy 
segítségével berendezzük saját házi 
ministúdiónkat, hiszen részletesen 
szól a hardver- és szoftverkövetel- 
ményekről, kitér az alkalmazott 
szabványokra, sőt még a szükséges 
kábelekre is. 

A Linux lelkivilágát mélyebben isme- 
rő, illetve az iránt érdeklődő felhasz- 
nálóknak szóló cikkek közt akad egy, 
amelyik egy speciális feladatütemezőt 
ismertet, a különleges műszaki megol- 
dások kedvelői pedig megtudhatják, 
hogyan lehet egy épület valamennyi 
légkondicionáló berendezését közpon- 
tilag vezérleni — természetesen Linux 
segítségével. 

Folytatódnak a korábban megkezdett 
sorozatok. Komáromi Zoltán a PHP 5 
újdonságait tárgyalja, mégpedig első- 
sorban az objektumközpontú lehető- 
ségek szemszögéből, Auth Gábor 

a külső programok telepítésének is- 
mertetésénél tart a FreeBSD bemutatá- 
sában, Dudás Ágnes pedig az átdolgo- 
zás jogával kapcsolatos részleteket tár- 
gyalja szoftverjogi sorozatának ebben 
a részében. Folytatódik Fábián Zoltán 
lassanként önálló rovatnak tekinthető 
sorozata, a GIMP bemutatása is. 
Ebben és a következő részekben 

a különböző modulokról és bővítési 
lehetőségekről esik szó. 


Kellemes időtöltést, jó szórakozást 
kíván a Linuxvilág csapata! 


0 Kiskapu Kft. Minden Jog fenntartva 





0 Kiskapu Kft. Minden Jog fenntartva 


A Linuxvilág jövője 


Avagy hova tűnt a Programvadászat rovat és a CD? 


Az elmúlt hónapokban gyakori 
vitatéma volt a szerkesztőségben 
a Linuxvilág jövője. 


e . Milyen legyen a kezdőknek, a ha- 
ladóknak és az abszolút profiknak 
szóló cikkek aránya? 


e Legyen-e CD? 


e — Egyáltalán van-e igény erre egy 
olyan korban, amikor a felhaszná- 
lók többsége egyre nagyobb sávszé- 
lességű kapcsolattal rendelkezik, és 
gyakorlatilag mindent, programot, 
dokumentációt, oktatóanyagot, hí- 
reket a netről szerez be? 


e . Legyen-e ennek a trendnek meg- 
felelően elektronikus kiadásunk, 
ami lehetővé teszi, hogy mindenki 
csak azokat a cikkeket fizesse elő 
vagy töltse le egyedileg, amelyekre 
valóban szüksége van? 


lalán ezek voltak a leggyakrabban fel- 
merülő kérdések. Két felmérést is vé- 
geztünk, amelyek jelentősen segítet- 
tek bennünket abban, hogy a magazin 
új ,főcsapását" kijelöljük. 

lekintettel arra, hogy az olvasók, illet- 
ve potenciális olvasók többsége nyilat- 
kozott úgy, hogy jobban örülne egy 
CD nélkül megjelenő, de olcsóbb lap- 
nak, 2005-től a mellékletet megszün- 
tettük, a lap árát pedig jelentősen 
csökkentettük. 

Szeretnénk azonban rögvest leszögez- 
ni: ez nem azt jelenti, hogy soha töb- 
bé, semmilyen formában nem lesz CD 
vagy DVD. Valószínűleg a gyors és 
egyre olcsóbb internet korában is szá- 
mos, a digitális külvilágtól még rész- 
ben elszigetelt embernek lehet szüksé- 
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ges például arra, hogy lemezen jut- 
hasson hozzá egy-egy újabb terjesz- 
téshez, amit nem tud letölteni. Nekik 
valamilyen formában mindenképpen 
segítséget kívánunk ehhez nyújtani, 
hiszen egyik célunk éppen a Linux 
terjedésének elősegítése. 

Hamarosan beindul egy olyan elektro- 
nikus előfizetési rendszer is, amelyen 
keresztül az egyes cikkek egyenként is 
letölthetők lesznek. 

lerveink közül a leglényegesebb azon- 
ban a lap ,alapstílusának" megváltoz- 
tatása. Bár a felmérések azt mutatják, 
hogy a jelenlegi előfizetőknek leg- 
alább a fele a , profi" kategóriába tarto- 
zik, úgy érezzük, a példányszám nö- 
vekedésének - a magas ár mellett — 

a leglényegesebb fékező ereje az volt, 
hogy a haladó illetve középhaladó fel- 
használók nem találtak kellően sok 
nekik megfelelő cikket. 

A jövőben tehát sokkal inkább az al- 
kalmazások bemutatására szeretnénk 
koncentrálni, és nem a csak informati- 
kai szakemberek számára érthető kü- 
lönleges műszaki megoldásokra és fej- 
lesztésekre. Ezzel párhuzamosan való- 
színűleg komoly változások lesznek 

a rovatok szerkezetében is. Újak jelen- 
nek meg, egyesek pedig eltűnnek, 
vagy más néven bukkannak majd fel. 
Erre az elég komoly stílusváltásra 
ebben a pillanatban még nem va- 
gyunk teljesen felkészülve, tehát 

csak fokozatosan, néhány hónap 

alatt tudunk majd a fent vázolt irány- 
ba elmozdulni. 

Végül néhány szó a teljesen kez- 
dőkről. Félreértés ne essék, ezt a kife- 
jezést most nem a levelezési listákon 
megszokott értelemben használjuk. 
Számunkra teljesen kezdő az, aki még 
soha nem látott Linuxot, soha nem te- 


lepített még önállóan ilyen rendszert, 
és jó esélye van rá, hogy ha ez sike- 
rülne is neki, akkor se találná meg 

a módját annak, hogy megjelenítse 
például egy a meghajtóba helyezett 
CD tartalmát. 

Az ilyen felhasználók problémái jó 
esetben erősen átmenetiek. Egy jó 
könyv elolvasása és néhány napi vagy 
akár pár órányi , játék" után rendsze- 
rint minden világossá válik. Ez pedig 
azt jelenti, hogy ettől a ponttól kezdve 
jó esélyük van arra is, hogy megértsék 
a haladóknak és középhaladóknak 
szóló cikkeket. 

Mindebből az következik, hogy 

a teljesen kezdőknek nem lesz külön 
rovata a lapban, egyszerűen azért, 
mert ez nem oldható meg. Értelmet- 
len volna minden hónapban közölni 
mondjuk egy-egy terjesztés telepíté- 
sének részletes leírását, hiszen 

a többség ebből semmit nem profitál- 
na, az a néhány , újonc" pedig, aki 
éppen akkor csöppent bele a Linux 
világába a következő számig már túl 
is van a traumán. 

Őszintén hisszük, hogy a fent vázolt 
elhatározásaink jelenlegi és leendő 
olvasóink örömére szolgálnak majd, 
és munkánkkal hozzájárulhatunk 

a szabad szoftverek és a Linux elter- 
jedéséhez Magyarországon. 

A változásokkal kapcsolatban termé- 
szetesen szívesen veszünk minden 
észrevételt, javaslatot! Igyekszünk 
minden ésszetű felvetést megfontolni, 
és minden levélre válaszolni. 


A véleményeket a 
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címre várjuk. 


A Linuxvilág stábja 


Wattok garmadája 

A japán SNE minden eddiginél na- 
gyobb teljesítményű tápegységeket 
dobott piacra asztali gépekhez. A 950, 
900 és 850 W teljesítményű tápok nor- 
mál ATX szabvány szerinti házakba, 
illetve EPSI2V rendszerekbe, vagyis 
munkaállomásokba építhetők be. 

A célközönség - noha egy korszerű, 
csúcsteljesítményű munkaállomás is 
komoly energiafogyasztással dicseked- 
het - egyértelműen a tuning iránt ér- 
deklődők közössége. Ugyanakkor 

a gyártó arra is felhívja a figyelmet, 
hogy tápegységei a fenti különlegesen 
nagy teljesítményt csak rövidebb ideig 
bírják, huzamosabb működésük során 
ennél kisebb terhelést viselnek csak el. 
Az extrém tápok ára rendre 570, 475 
és 427 dollár, vagyis 100000 forint 
körül mozog. 
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Pofákat vágnak 

A kanadai Sheridan Műszaki és Fejlett 
Tanulási Intézet a Torontoi és a Oueens 
Egyetemmel együttműködve, a Silicon 
Graphics Onyx4 Ultimate Vision megje- 
lenítő megoldására építve a testbe- 
széd a korábbinál jóval pontosabb 
elemzésére alkalmas rendszert dolgo- 
zott ki. A végeredmény egy szimulált 
emberi arc, ennek mozdulatait, kifeje- 
zéseit a kutatók rendkívül nagy rész- 
letességgel tudják szabályozni. 
Mindennapi életünk során akarva- 
akaratlanul mindannyian számos 
ilyen metakommunikációs elemet 
használunk, és sokat tudatosan vagy 
tudattalanul veszünk, értelmezünk is, 
ám a közöttük fennálló összefüggése- 
ket még nem sikerült részletesen fel- 
tárni. A jelenlegi kutatás egyik újdon- 
sága, hogy az arc egyes kifejezései, 
mozdulatai - az emberi arcoktól elté- 
rően — egymástól teljesen függetlenül 
szabályozhatók, így önálló jelentésü- 
ket is pontosabban meg lehet ismerni. 
lermészetesen az emberi arc számító- 
gépes modellezése nem újdonság 

-— gondoljunk csak az újabb rajzfil- 
mekre -—, ám mindezt a pszichológu- 
sok és a nyelvészek igényeinek meg- 
felelő formában megvalósítani koránt- 
sem volt egyszerű. Az arcmodellt 

a kutatók egy emberi arc háromdi- 
menziós letapogatásával, az izomzat 
jellemzőinek figyelembe vételével ala- 
kították ki, ennek valós idejű leképe- 
zéséről gondoskodik a Silicon Image 32 
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darab szorosan csatolt grafikai 
processzora. A vizsgálatok eredmé- 
nyeit több területen, többek közt 

a kommunikációs nehézségekkel küz- 
dő, például autista személyek kezelé- 
se során is fel tudják majd használni. 


Solaris 10 


Hivatalosan is bemutatta Solaris 10 
operációs rendszerét a Sun. A három- 
ezer mérnöki emberóra árán és félmil- 
liárd dolláros fejlesztési költséggel fej- 
lesztett, több mint 600 új szolgáltatást 
tartalmazó Solaris 10 állítólag minden 
idők legfejlettebb UNIX operációs 
rendszere, mely január végére SPARC, 
x86 és 64 bites AMD és Intel processzo- 
rokra egyaránt elérhető lesz — még- 
hozzá ingyenesen. Az új rendszer leg- 
fontosabb újdonságai között szerepel 
a DIrace hibakereső eszköz, a szoftver- 
partíciók létrehozásának lehetősége, 

a folyamatok jogosultságainak kezelé- 
se, a prediktív öngyógyítás, a linuxos 
alkalmazások módosítások nélküli fut- 
tatása, a hatalmas kapacitású ZES fájl- 
rendszer és a titkosítási keretrendszer. 
lermészetesen az 1991 óta fejlesztett 
operációs rendszer ingyenessé tétele 
miatt sem kell a Sun-t a tönkremene- 
teltől féltenünk. A cég az utóbbi idő- 
ben egyre inkább a termékeihez fűző- 
dő szolgáltatásokból, előfizetésekből 
próbál tennmaradni, ennek az átállási 
folyamatnak a része a Solaris ingye- 
nessé tétele is. 

Ugyanakkor a Solaris jövőjét sem akar- 
ják csupán az asztali és kiszolgáló gé- 
pekre alapozni, a Sun is ki akarja hasí- 
tani a maga szeletét a beágyazott ké- 
szülékek piacáról, amely egyébként 

a legyártott processzorok 60 százalé- 
kát használja fel. Ehhez a Solarisnak 
kisebb teljesítményű gépeken is mű- 
ködnie kell, továbbá magas fokú 
modularitás biztosításával lehetővé 
kell tenni a fejlesztők számára, hogy 
ki tudják választani az adott készülék 
működtetéséhez szükséges program- 
részeket. Mondhatnánk, hogy a Sun 
kissé későn ébredt, hiszen a Linux 
vagy a Windows átszabott változatai- 
nak fejlesztése már évek óta folyik, 
ám a Java révén a cég nem teljesen 
járatlan ezen a területen, és a Solaris 
későbbi, a különleges igényeknek 
még jobban megfelelni képes válto- 
zataival jó esélye van a hangsúlyos 
szereplővé válásra. 

2 www.sun.com 
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Mindentudó Opera 

Az Opera Software megkezdte új, 
Extensible Rendering Architecture (Bővít- 
hető Leképező Architektúra, ERA) nevű 


OPERA 


K. ; jú EZ Bal ES 
alJi (vala 





leképező-megjelenítő megoldását al- 
kalmazó, asztali gépekre készült bön- 
gészőjének tesztelését. A várhatóan 

a 7.60-as Operában megjelenő alrend- 
szer a kis- és közepes méretű, az asz- 
tali gépekre jellemző és a tévés képer- 
nyők, monitorok kezelésére egyaránt 
képes lesz. Az ERA dinamikusan át 
tudja méretezni a weboldalak tartal- 
mát, így az oldalakat bármekkora mé- 
retű képernyőn képes úgy megjelení- 
teni, hogy a felhasználónak oldalirá- 
nyú görgetést nem kell végeznie. 
Mivel így a teljes tartalmat könnyen át 
lehet majd tekinteni, könnyebbé, élve- 
zetesebbé válik a használat, és várha- 
tóan újabb alkalmazási területek nyíl- 
nak meg az Opera előtt. 
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Sosem áll meg 

Az NEC Solutions America magas fokú 
hibatűrésre képes, Linux alapú kiszol- 
gáló gépet mutatott be. A 99999 száza- 
lékos rendelkezésre állású, Express5800/ 
320Lb jelzésű számítógép kialakításakor 
semmit nem bíztak a véletlenre: 
gyakorlatilag mindenből kettőt vettek. 





A számítások végrehajtásáról összesen 
négy Xeon MP processzor gondosko- 
dik, ezeket két modulra osztották el. 

A modulok külön 4 egység magas fió- 
kokban helyezkednek el, és szinkron 
működésüknek köszönhetően bármi- 
kor képesek átvenni egymástól a vég- 
rehajtást. A gépen 2.4.18-as Linux rend- 
szermag fut, ezt a hozzá tartozó illesz- 
tőprogramokkal együtt a magas ren- 
delkezésre állás követelményeinek 
megfelelően szabták át az NEC mérnö- 
kei. Az Express5800/320Lb ára 25500 
dollártól, vagyis körülbelül ötmillió fo- 
rinttól indul. 

2 www.nec.com 
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Kettőslátás 

Az Asus lett az a gyártó, amely első- 
ként mutatta be az NVIDIA egyes 
grafikus kártyái által támogatott SLI 
(Scalable Link Interface) megoldás 
kihasználására alkalmas, AMD pro- 
cesszorokat fogadó alaplapját. 

Az A8N-SLI Deluxe a szokásos egytől 
eltérően két PCI Express (PCI-E) x16 
foglalatot tartalmaz, így két VGA kár- 
tya behelyezését is lehetővé teszi. 

A kártyákat egy apró modullal kell 
összekötni, ettől kezdve egymással 
együttműködve képesek megosztani 
a leképezési feladatokat, amivel gya- 
korlatilag megkétszerezhető a megje- 





lenítés teljesítménye. Az Asus alaplap- 
jának tervezésekor nemcsak az SLI 
modul elhelyezését kellett figyelembe 
venni, de a nagyteljesítményű VGA 
kártyák áramfelvételét és hőterme- 
lését is. lermészetesen, hűen a korábbi 
Deluxe jelzésű alaplapok hagyomá- 
nyához, az Asus nem elégedett meg 
ennyi extrával, az alaplap AI NOS 
szolgáltatása intelligens eljárásokkal, 
mindig a szükséges pillanatban képes 
növelni a processzor órajelét, az AI 
NET az operációs rendszer elindítása 
előtt is képes felismerni a hálózati ká- 
belek hibáit, az összesen nyolc SATA 
csatlakozón akár két különálló RAID- 
rendszert is kialakíthatunk, a hálózati 
és egyéb kapcsolatok létrehozására 
pedig két gigabites LAN csatoló és két 
Firewire csatoló áll rendelkezésünkre. 
2 Wwww.asus.com 


GPL 3.0 

A Free Software Foundation megkezdte 
a GNU General Public License újabb, har- 
madik változatának kidolgozását. Az 
ESF keretein belül eredetileg Richard 
Stallman készítette a szerződést, mely- 
nek legújabb változata 1991-ben látott 
napvilágot. lermészetes, hogy 14 év 
alatt a szoftverek világ hatalmasat vál- 
tozott, így a kamaszkorba lépő szerző- 
dés képtelen az újabb követelmények- 
nek megfelelni. A legújabb kiadásban 
a készítők igyekeznek figyelembe ven- 


ni a szellemi tulajdonnal és a szabadal- 
makkal összefüggő, a hálózati haszná- 
lat, a webszolgáltatások indítása kap- 
csán megjelenő és a megbízható számí- 
tástechnika várható elterjedése során 
felmerülő kérdéseket. Iovábbi kiküszö- 
bölésre váró problémaforrás az egyes 
országok szabadalmi jogrendszerének, 
sőt, jogi hagyományainak eltérése, ami 
önmagában is jelzi a munka nehézsé- 
gét. A GPL 3 elkészítése mindettől füg- 
getlenül több mint időszerű - ezt ön- 
magában is igazolja az a tény, hogy az 
idők során több mint ötvenféle félig- 
meddig szabad szerződést készítet- 
tek —, elődje az eredetileg tervezettnél 
már így is jóval tovább szabályozta 

a szabad programok világát. 


Leckekereső 

Google Scholar névvel új kereső szolgál- 
tatást indított a G0097/e. A cél a legkülön- 
félébb területekhez kapcsolódó tudo- 
mányos jellegű írások, műszaki jelenté- 
sek, egyetemi weboldalak és könyvek 
elérésének segítése. Mindezek a tartal- 
mak ugyan felkerülnek a webre, ám 
túlnyomó részük csak jelszó megadásá- 
val, sokszor előfizetés birtokában érhető 
el, ami rendkívül megnehezíti az adott 


Google 


témában keresgélő látogatók, és persze 
a keresőmotorok dolgát. A Google csa- 
pata számos egyetemmel, kiadóval 
együttműködve valósította meg a kere- 
sőt, mely ugyanakkor teljes értékű hoz- 
záférést nem biztosít, ám az írások rö- 
vid kivonatait könnyen elérhetővé te- 
szi. A kereső érdekessége, hogy a talála- 
tokat — a Google normál kereséseihez 
hasonlóan - nem a látogatottság, ha- 
nem a más szerzők által végzett idézé- 
sek alapján rangsorolja. Felmérések 
szerint az utóbbi években a kutatók és 
a diákok egyre inkább a webes források 
felé fordultak munkájuk és feladataik 
megoldása során - ezt az irányzatot 

a keresőknek is követniük kell. 

2 www.google.com/scholar 


Medgyesi Zoltán 
(mzarettesoft.hu) 

A Linuxvilág hírszerkesztője. 
Szabadidejét legszívesebben 
a barátnőjével tölti, szeret 
autózni és bográcsban főzni. 
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Ni újság a rendszermag fejlesztése körül? 


Közel egy évnyi versengés után a pmdisk és az 
swsusp újra swsusp-ként egyesül. Fejlesztését to- 
vábbra Is Pavel Machek fogja vezetni, amiben az 
egykori szétválást kezdeményező Patrick Mochel, 
illetve a szoftveres felfüggesztés terén érdekelt fej- 
lesztők segítségére egyaránt számíthat. Patrick 
szívhez szóló bocsánatkérést intézett Pavelhez 

a kód szétágaztatása miatt, s ettől kezdve szépen 
együtt folytatták a munkát, megosztva a foltokat 
és átbeszélve a műszaki jellegű kérdése- 
ket. Jó látni, hogy a vita elsimult, 
ugyanis alapját közös szenvedé- 
lyük adta, nevezetesen a kód 
lehető legjobbá tétele annak 
érdekében, hogy biztos mű- 
ködésű szoftveres felfüg- 
gesztési szolgáltatást való- 
sítson meg, és a lehető 
legkevesebb gond árán 
válhasson a hivatalos rend- 
szermag részévé. 


A cryptoloop nagy valószínű- 
séggel kikerül a 2.6-os sorozatból, 
hacsak Andrew Morton meg nem 
várja ezzel a 2.7-est. Bárhogy is történik, 

az tisztán látható, hogy a cryptoloopnak mennie kell. 
A kód, melynek segítségével a felhasználók a helyi 
hurkon keresztül titkosított fájlrendszereket fűzhet- 
nek be, a jelek szerint nemcsak hibás, de karbantar- 
tás nélkül Is maradt, ráadásul súlyos biztonsági hil- 
báktól terhes. Andrew szempontjából leginkább 

a biztonsági hiányosságok teszik elfogadhatatlanná 
a cryptoloopot. Jobb, ha nem áll rendelkezésünkre 
egy lehetőség, mintha egy a biztonságot hamisan 
ígérő szolgáltatást használnánk. lermészetesen, 
mint arra több fejlesztő Is felhívta a figyelmet, az 
ilyen nagyobb változtatásokat soha nem szabad(na) 
üzembiztos sorozaton végrehajtani, de így Is legfel- 
jebb késleltetni lehet az elkerülhetetlent. Hacsak va- 
laki színpadra nem lép, és el nem vállalja a karban- 
tartást és a biztonsági hiányosságok pótlását, 

a cryptoloop jövője igencsak rövid lesz. 


A Reiser4 fájlrendszer, amely rendkívül messze 
került a Reiserő változattól, az -mm rendszermag- 
sorozat (Andrew Morton saját fája) része lett, és 
öles léptekkel halad a hivatalos kiadás részévé vá- 
lás irányába. A Aeiser-rajongók természetesen lel- 
kesednek, miközben rohamosan nő a felhasználói 
tábor, és vele együtt a hibajelentések száma is. 

A Reiser4, mely egyelőre csak a fő szolgáltatáso- 
kat tartalmazó változatban jutott el Andrew-hoz, 
állítólag a linuxos világ leggyorsabb fájlrendszere. 
Persze ilyesmit állítani még jogosan is csak ideig- 
óráig lehet, azt viszont kár volna kétségbe vonni, 
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hogy az újabb generációs fájlrendszerek kiváló 
általános teljesítményt nyújtanak, ami főleg az 
intenzív lemezhasználattal járó alkalmazások fut- 
tatásakor fontos. 


Andrew Morton, mint a 2.6-os sorozat karbantartója 
kétségbe vonta néhány hagyomány fenntartásának 
értelmét, ilyen például az üzembiztos és a fejlesztői 
rendszermagsorozat fenntartása. Ugyan annyira 
azért nem rúgná fel a meglévő rendszert, 
hogy megszüntesse a párhuzamossá- 
got, ám szerinte inkább a terjesz- 
tések készítőire kellene bízni az 
üzembiztosság megteremté- 
sét. A hivatalos 
rendszermagforrások 
összeállításakor szerinte 
— az üzembiztosság mel- 
lett, és nem helyett — a se- 
bességre és a szolgáltatá- 
sok bővítésére kellene össz- 
pontosítani, és az üzembiz- 
tosságra nem kellene olyan ki- 
emelt figyelmet fordítani, mint az 
utóbbi néhány fő kiadás esetében. 

A kérdéssel kapcsolatban sokféle állás- 
pont létezhet és létezik, ám ne feledjük, Andrew, 
Linus és a többiek mindig saját ötleteik és a mások- 
tól kapott tanácsok alapján módosítják a fejlesztési 
modellt. Andrew legújabb ötletére némi jóindulattal 
úgy tekinthetünk, mint a rendszermag fejlesztési 
munkálataiban segédkezők körének kibővítésére tett 
kísérletre, amelynek eredményeként a terjesztések 
készítői is a folyamat teljes jogú, elsődlegesen az 
üzembiztosságra ügyelő résztvevőivé válnának. 


A DevFS, mely a Linux történetében a legnagyobb 
viták egyikének tárgya volt, a jelek szerint egyre In- 
kább sodródik afelé, hogy végleg kikerüljön a rend- 
szermagból. Andrew Morton úgy nyilatkozott, hogy 
a 2.8-as rendszermagban már biztosan nem lesz 
DevFS, a végleges eltávolítást 2005 közepére terve- 
zik. Mindig Is erősek voltak azok a hangok, amelyek 
a DevFS megtartását követelték, amíg helyettese, 
az udev nem képes a DevFS összes szolgáltatását 
biztosítani. Hibái ellenére a DevFS-t bizony nem lesz 
könnyű leváltani. Richard Gooch hatalmas mennyit- 
ségű munkát ölt bele, és az Alexander Viro és má- 
sok részéről érkezett rengeteg bírálat ellenére máig 
sem sikerült lecserélni — közel két évvel azután, 
hogy Hichard felhagyott a tervezettel és a rendszer- 
mag fejlesztésével. 


Zack Brown 


Linux Journal 2004. december, 128. szám 
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TextMaker Zaurushoz 

A német SoftMaker cég 

a lextMaker nevű szövegszer- 
kesztője Immár elérhető Z/aurus 
platformon Is. A TextMaker for 
Zaurus konvertálás nélküli közvet- 
len dokumentumkapcsolatot tesz 
lehetővé más JextMaker platfor- 
mokkal az eredeti formázás meg- 
tartása mellett. A dokumentum- 
csere terén több Microsoft Word 
verzió, valamint egyéb fájlformá- 
tumok között válogathatunk, pél- 


Edit 
MEN 
Farrnat 
Insert 
übject 


Extras 


virndoi 


Recent 


b 

b 

b 

b 

k á 
Table b reööR8 

b 

b 

b 

b 


Help 


dául használhatjuk a H/ML, RIF, 
ASCII és Unicode szabványokat. 
Ezen kívül többnyelvű helyesírás 
elemző és elválasztás kezelő 
programot tartalmaz, a vezérlőcsí- 
kok és a billentyűzetkiosztás telje- 
sen testre szabhatóak, valamint 
beépített dBase rendszerű adat- 
bázis és fájlkezelő rendszerrel ren- 
delkezik. A JextMaker for Zaurus 
bármelyik Z/aurus módban futhat, 
kezeli a nagy felbontású képer- 
nyóket és fekvő lapállást, valamint 
a belső memóriába és memórla- 
kártyára is telepíthető. 
www.softmaker.co 


Appro 1U és 4U Ouad 
Opteron Kiszolgálók 

Az Appro bejelentette két új, négy 
Opteron processzor köré épített, 
1U-1142H és a 4U-4148H jelű 
kiszolgálóiít. A maximum négy 
Opteron processzorral rendelkező 
1U-1142H Ouad Opteron Server 
párhuzamosan 32-bites és 64- 
bites számítási képességgel ren- 
delkezik, maximum 32GB ECC 
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333/400 DDR memóriát kezel, két 
IDE, SCSI vagy SATA HDD-t, vé- 
kony FDD és CD meghajtókat 
vagy DVD-ROM meghajtót tartal- 
mazhat és egy teljes PCI-X 64- 
bit/133MHz hellyel rendelkezik. 

A 4U-4149H ezen felül nyolc 
SATA vagy SCSI HDD-t, maximum 
öt PCI-X helyet és 3.25" FDD illet- 
ve 5.25" meghajtóhelyeket tartal- 
maz CD/DVD-ROM vagy szalagos 
egységek számára. Mindkét kI- 
szolgálót távoli kiszolgálóvezér- 
léssel és nagy sebességű kapcso- 
lattal szállítják. 

www.appro.com 


PeerFS Adatmásolat készítés 


A Radliant Data Corporation kihoz- 
ta PeerFS nevű, Linux alapú üzleti 
alkalmazásokhoz szánt egyenran- 
gú (peer-to-peer), folyamatos má- 
solatkészítő megoldását. 

A PeerFS POSIX-szabványú fájl- 

rendszer, mellyel több forrásból 

származó és több célnak szánt 


JN "vera FrotoOtON 
UNUK UNA UNZK 
Apygyaratesát fianateter aaz etmzatssan Brrr ADPÜCEVOIN Harvor Appácsoan Beroom 
TS TER 
Laza 
Ledc Mödltstááe Mlásoztsdai 
Margin Pusnt af Pasnaru 


FinuarvaruTg Gt UTep Osztan hapsi 
Muturraroa Patrver 


adatok egységesen és napraké- 
szen tarthatók. Az adat folyama- 
tosan látható és felhasználható 
bármely helyi alkalmazás számá- 
ra. A PeerFS képes egyidejű mű- 
veleteket végezni több kiszolgá- 
lón található különböző célokon, 
szétválasztott de logikailag azo- 
nos adattárolókon, megkönnyít- 
ve a MySOL és más webkiszol- 
gáló összetevők kezelését. leljes 
256-bites AES titkosítást lehet 
beállítani bármely végponton, 
továbbá a PeerFS a végpontok 
között tárhely leállás esetén Is 
zökkenőmentes hibakezelést biz- 
tosít. A PeerFS bármely alkalma- 


zással vagy adatbázissal képes 
együttműködni és nem kényes 
az alkatrészekre. 
www.radiantdata.com 


Adonis DNS/DHCP eszköz 

A BlueCat Networks Adonis 
DNS/DHCP Appliance eszköze 
egyenesen a vállalati hálózatba 
épül be, az egységes vállalati IP 
beállítás és gépnévkezelés érde- 
kében integrálva a DNS és DHCP 
szolgáltatásokat. A legfrissebb 
Adonis eszköz már tartalmazza 

a crossover high availability (XHA) 
nevű szerkezetet amellyel elkerül- 
hető a DNS és DHCP szolgáltatá- 
sok leállása; az IP kölcsönzés el- 
osztását táblázatos vagy grafikus 
formátumban megjelenítő /ease 
viewer kezelőfelületet, egy adat 
ellenőrző rendszert, amellyel 

a DNS és DHCP beállítások telepí- 
tése előtt felderíthetők a hibák, 
valamint maximum 100 szintű 
visszavonási és másol/vág/ 
beilleszt funkciókat kínáló egy- 
szerűsített szerkesztést. 
bluecatnetworks.com 


BITMICRO Networks E-Disks 


A BIIMICRO Networks bemutatta 
új fajta, E-Disks néven futó, ho- 
mogén, lemez alapú ISCS/ cél 
eszközét. Az E-Disks Fibre 
Channel, Ultra320 

SCSI, PATA és 
SATA vál- 
tozatban 
kapható. 
Bármely vál- 
tozatot alkalmaz- 
hatjuk vállalati környe- 
zetben, Internetes kommunikáció- 
ban és hagyományos Ipari alkal- 
mazásokban. Az E-Disks szilárd, 
kezelhető, együttműködő és ke- 
zelhető F/ash-alapú hálózati tároló 
megoldás kíván nyújtani, amely 
nagy távolságokra ér el, könnyen 
összekapcsolható SAN rend- 
szerekkel, több felhasználó 
használhatja párhuzamosan és 
könnyen boldogul a már létező 
alkalmazásokkal. 
www.bitmicro.com 
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1. A Linux előre jelzett növekedési ütemének 
számjegyeli: 2 


2. Azon UNIX felhasználók százaléka, akik szívesen 
váltanának platformot: 4 


3. Azon Microsoft Windows felhasználók százaléka, akik 
szívesen váltanának platformot: 10 


4. — Nyílt forráskódú projekteken dolgozó fejlesztők száma 
Észak Amerikában, millióban: 1.1 


5. . Észak Amerikában legalább ennyi millió fejlesztő 
dolgozik 64-bites rendszereken: .5 


6. . Észak Amerikában közel ennyi millió ember dolgozik 
grid számítási projekteken: .25 


7. Észak Amerikában közel ennyi millió fejlesztő dolgozik 
fürtözött megoldásokon: .5 
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8. — Az fürtözött megoldásokon dolgozó Észak Amerikai 
számítástechnikai fejlesztők százaléka: 1/ 


9. Ennyi ezer párhuzamos hanghívást képes kezelni 
percenként a Linux alapú Készültségi Válaszadó 
Rendszer (Emergency Response System): 10 


10. Ennyi ezer párhuzamos bejövő forródrótot tud kezelni 
az ES 80 


11. Ennyi ezer párhuzamos fax hívást kezelhet az ERS: 5 


12. Ennyi ezer párhuzamos szöveges üzenetet kezelhet 
az Eho 9 


13. Az internet százalékos növekedési üteme az elmúlt 
12 hónap alatt 2004-ig bezárólag: 26.1 


14. Ez alatt az időszak alatt felvett új gépnevek száma 
millióban: 10.7 


15. A Netcraft által felmért helyek száma 2004 júniusában 
millióban: 51.635284 


16. — Ennyi millió helyen futtatnak Apache kiszolgálót: 
34.7/10235 


17. A összes kiszolgálóhoz képest az Apache százalékos 
aránya: 67.22 


18. Az részesedésének növekedése a múlt hónapban: .17 


19. Microsoft [IS rendszert futtató kiszolgálók százalékos 
aránya: 21.35 


20. A Microsoft IIS csökkenése a múlt hónapban: -0.13 


Források 


1-3. . LinuxWorld, a Yankee Group jelentéséből válogatva 
4-8: " Evans Data Corporation 
9-12: . Emergency Response Network 
13-20: — Netcraft 
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A Linux Journal 
honlapján számtalan 
gond megoldásához 

találhattok további 
segítséget. A Sunsite 
tüköroldalait, a gyakori 
kérdéseket és az egyéb 

útmutatásokat a 

5Wwww.Inuxjournal.com 
honlapon olvashatjátok 
el. A rovatban közzétett 
válaszokat LInux-szak- 
értők kis csapata készí- 
tette el. További kérdé- 
serteket szívesen fogad- 
Ják (angol nyelven) a 
D5www.lIinuxjournal. com/ 
[-issues/techsup.htmi 
címen, ahol csak egy 
kérdőívet kell kitöltene- 
tek, de a bts(ossc.com 
címre levelet is írhattok. 
A levél tárgyában 
szerepeljen a, BIS" 
kulcsszó. 
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A hónap szakmai tanácsai 


Megjelenítés problémák Compag Laptopon 
Compag Presario 2500-as gépet és Fedora Core 2-t 
használok. Az a gond, hogy képernyő állandóan be- 
szűkül, de fogalmam sincs mi okozza. Mit tegyek? 
Anonymous, 

s. CCOAOOZLST B KÖKTEMEBÜNN 


Az általad leírt problémához hasonló esetek ismere- 
tesek az AfI RADEON videókártyákkal kapcsolatban. 
Valószínűleg a te Presario 2500-asod is ilyet használ. 
Érdemes megpróbálni az /etc/X1 1/xorg.conf állo- 
mányban megjegyzésbe tenni a Load dri sort, 
majd újraindítani az X kiszolgálót. Előfordulhat 
azonban, hogy ez az adott gépen váratlan ered- 
ményhez vezet. 

Felipe Barousse Boué, 

2 fbarousseOpiensa.com 


ACPI, Sleep és Standby 


ASUS L8400B laptopom van, 700MHz P-III pro- 
cesszorral. Nemrég tettem fel a Fedora Core 2-t 
2.6.5-ös rendszermaggal. Ez a rendszermag ACPl-t 
használ a 2.4-es sorozatban alkalmazott APM he- 
lyett, így a laptop működésének felfüggesztése 
máshogy, elég idegesítően működik. 

APM alatt az apm paranccsal tudtam sleep vagy 
standby módba váltani. Az első amennyire én tu- 
dom, mindent a memóriában tart; a második, gon- 
dolom, a lemezre mentené a környezetet majd alvó 
állapotba lép. A laptop felébresztéséhez mindkét 
esetben mindössze egy billentyűt kellett megnyom- 
nom a laptopon. 

ACPI alatt, ezt látom a /Ssys/pbower/state fájlban: 


standby mem disk 


A disk szót küldve a /sys/bower/state-be semmi 
sem történik. Bármelyik másik kifejezést küldve 

a laptop futása felfüggesztődik. Csakhogy nem éb- 
red fel amikor a billentyűzetet csapkodom. Kizárólag 
akkor ébred fel újra ha a bekapcsológombot haszná- 
lom. Csakhogy ilyenkor a rendszer észleli, hogy 
megnyomtam bekapcsológombot és azonnal elin- 
dítja a rendszerleállítást. 

A Google-lel végzett keresés nem sok eredmény- 

re vezetett, az ACPI FAO úgy tűnik legalább 

három éves. 

Szóval a közvetlen kérdéseim: 


1)  lámogatott felfüggesztés lemezre funkció? 
Ha igen, hogy lehet beizzítani? 

2) Hogyan kell helyesen felébreszteni 
a laptopot? 

3) Mit kell még tudnom? Eléggé kezdő vagyok 
ACPI terén. 
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Ha lehet kerülném a rendszermag frissítését és ha- 
sonlókat, de megcsinálom ha valami javulást hoz. 
Arnold Robbins, 

9 arnoldoskeeve.com 


A felfüggesztés lemezre azon a laptopon a BIOS 
egyik szolgáltatása. Ha a Linux telepítésekor töröl- 
ted a mentési partíciót, akkor újra létre kell hozni. 
Egy másik ASUS tulajdonos hasznos tanácsai: 
linux.seindal.dk/item20. html. 


Amennyiben érdekel az ACPI beállításaid testre sza- 
bása, könnyebben megy a hibakeresés ha a megfe- 
lelő init scriptet stop paraméterrel meghívva leállí- 
tod az acpid démont, és a -d kapcsolóval az előtér- 
ben indítod el. Így láthatod, milyen ACPI események 
lépnek életbe és módosíthatod a megfelelő pa- 
rancsfájlokat. 

Don Marti, 

9 dmarti(gdssec.com 


A Daktronics hátrányos megkülönböztetést 
használ a linuxos vásárlókkal szemben 

Miért választja a legtöbb alkatrészgyártó a Microsoft 
modellt a Linux modellel szemben? Miért nem fej- 
leszt mindkettőre? A LED jelek jelentős fejlesztője, 
a Daktronics például kizárólag Microsoft termékeket 
használ a fejlesztőkészleteiben. A cégnek van ugyan 
protokoll útmutatója de semmiféle segítséget nem 
nyújt a Linux osztott könyvtár modelljéhez. 

Én a linuxos modell szerint fejlesztek ezekhez a kijel- 
zőkhöz, de ennél a munkánál is úgy tűnik a Micro- 
soft fejlesztés felé billen a mérleg. Hogyan lehetne 
rávenni a gyártókat, hogy könyvtárakat készítsenek 
a linuxos fejlesztés meggyorsítására? lovábbra 

is folytatni fogom a projekt fejlesztését, mivel 

úgy érzem, hogy a Nyílt Forrású közösség valami 
hasznát látja az ilyesfajta kijelzők meghajtóinak. 

Ha tudnátok valamilyen információt adni hasonló 
témával foglalkozó emberekről vagy csoportról, 
szívesen venném. 

Chuck Smith, 

9 chucksmithoviawest.net 


Bár természetesen pártfogó csoportok is elérhe- 
tők, ilyen például az OSDL, a legtöbb gyártó csak 
egyetlen dologból ért -— a vásárlói nyomásból. Csat- 
lakozz a kórushoz, lépj kapcsolatba a cég minden 
képviselőjével akivel csak tudsz és mondd el nekik, 
hogy szeretnéd ha felkarolnák a Linuxot. A legtöbb 
gyártó már elkezdett dolgozni ezen a területen, 

de sokan nagy kihívásnak találják egy új operációs 
rendszer alatti fejlesztésbe belevágni, Így erős ösz- 
tönzésre van szükségük. Türelemre és sok Ismét- 
lésre van szükség, hogy hangot adhassunk véle- 


Ni a 


ményünknek. Bátorításul; az elkövetkező két évben 
egyre ritkább lesz az olyan gyártó, aki semmibe 
veszi a Linuxot. 

Chad Robinson, 

9 chadolucubration.com 


Becsülendő, hogy egy projekten szeretnél dolgoz- 
ni, de ha egy üzleti fejlesztőkészlet licenszéhez 
vagy kötve, elképzelhető, hogy nem adhatod ki 
a saját hasonló képességeket nyújtó nyílt forrású 
kódodat. Érdemes ellenőriztetni egy hozzáértő 
ügyvédi irodával például a rosenlaw.com-on 

— valószínűleg jobban jársz, ha olyan projekten 
kezdesz dolgozni, ahol soha nem kattintottál 

a kínos ,/ Agree" gombra. 

Don Marti, 

9 dmarti(dssec.com 


Linux kapcsolat a régi 

Microsoft Exchange-hez? 

Remélem létezik válasz erre a kérdésre; minden- 
fele kerestem a megoldást és szinte semmit sem 
találtam. Mostanában szeretnénk megjelentetni 
Java Desktop rendszereket, de rá kellett ébred- 
nünk, hogy az Evolution nem támogatja az MS 
Exchange naptárazást és egyebeket. Megpró- 
báltuk működésre bírni, Így végül a Xímian 
Connector segítségét vettük igénybe, csakhogy 
az viszont nem működik együtt az Exchange 5.5-el. 
Biztosan van más is a Xímian-on kívül. Mivel elég 
új fiú vagyok a "nix területén fogalmam sincs 

mit lehetne helyette használni. ludsz esetleg bár- 
milyen más programot amely képes összekap- 
csolni Evolution e-mail ügyfeleket MS Exchange 
kiszolgálóval? 

Monigue Marais, 

9 monigue.maraisoalindigo.com 


Olyan régi Exchange verziód van, amelyet már 

a Microsoft sem támogat tovább. Rengeteg megol- 
dás létezik levelezésre és naptárazásra Linux alatt; 
vannak köztük ingyenesek és üzleti megoldások is. 
Vess egy pillantást 

a www.calendarhome.com/clinkíweb-calendar.html 
listájára ha ilyesmit keresel. 

Felipe Barousse Boué, 

2 fbarousseOpiensa.com 


Előbb vagy utóbb úgyis frissítened kell azt a régi 
Microsoft Exchange programot, ha időt akarsz 
nyerni, esetleg meg lehet próbálni VNC ügyfeleket 
telepíteni az új Linux rendszerekre és VNC kiszol- 
gálót a Microsoft oldalra, így a felhasználók elérhe- 
tik a régi alkalmazásokat. A témáról bővebben 

itt olvashatsz: 
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www. linuxmafia.com/fag/ Legacy Microsoft/ 
vnc-and-similar.html. 

Don Marti, 

a) dímarsse. com 


Point-of-Sale rendszer? 


Egy jó POS rendszert keresek három alkalma- 
zottat foglalkoztató kis kiállításhoz. Red Hat 9-et 
használok és ingyenes vagy kedvező árú meg- 
oldást keresek. 

Randy Freer, 

9 freersocharter.net 


Végignéztem jó néhány szép POS rendszert, 
amelyek esetleg megfelelhetnek az igényeidnek. 
Nézz körül a www. linux-pos.org lapon, ez a lap 
a kiskereskedelmi Linux alkalmazásokkal foglal- 
kozik. Itt rengeteg üzleti alkalmazásra szánt 
szabad programot találsz, többek közt POS 
rendszereket IS. 

Azonban tartsd szem előtt, hogy céged igényeitől 
függően, elképzelhető, hogy elég sok mindent be 
kell építeni: pénztárgépet, vonalkód leolvasó rend- 
szert, címke nyomtatót és egyebeket. Ezért, nem 
rossz gondolat összehasonlítani a teljes birtoklási 
költséget (beleértve az idődet vagy valamilyen cég 
felkérését) az üzleti megoldásokkal, még ha Linuxról 
és Nyílt Forráskódú rendszerekről is van szó. 

Az üzleti megoldással támogatás és kulcsrakész 
indulás Jár, így nem kell magadnak összeilleszteni, 
felépíteni és kitalálni mindent. 

Felipe Barousse Boué, 

9 fbarousseOpiensa.com 


Alternatív levelezési megoldás 


Walter 2004 augusztusi Legjobb műszaki támoga- 
tás kérdésére válaszolva: Régen megoldottam 
már ezt a problémát, megtekintheted 

a www.trestle.com/linuxytrestlemail[/ 
bye-trestlemail.html címen. 


Igaz, ma már a Postfix kezeli a leveleimet így nincs 
szükség a IrestleMailrre. Teljesen egyetértek Felipe 
válaszával: ameddig többcélú (multidrop) levelet 
használsz, mindig problémát fognak okozni 

a rosszul kezelt határesetek (levelező lista levél, 
bcc-k és egyebek). Ezt nem lehet megkerülni. 
Ugyanakkor, ez az egyszerű megoldás megbízható, 
és teljes vezérlést ad neked a teljes levélforgalom 
felett. Lehet, hogy éppen a /restlemail az amire 
szükséged van. Nyugodtan szólj ha kérdésed akad. 
Scott Bronson, 

9 bronsongrinspin.com 
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AEMIM: saját méretezhető eseménykezelő Linux alá 


Tegyük képessé alkalmazásunkat rendszermag visszahívások regisztrálására. 


gy korábbi cikkünkben a telekommunikáció téma- 
körében felvetettük egy saját, általános eseményme- 
chanizmus szükségességét Linux alá. A Linux képes- 
ségeinek javítását célzó legtöbb megoldás kiábrándított 
bennünket. Mások nem feleltek meg igényeinknek, hiszen 
egy kommunikációs szintű (carrier-grade) rendszernek ko- 
molyabb valós idejű követelményei vannak. A siker érdeké- 
ben egy ilyen eseménymechanizmusnak szorosan kell kap- 
csolódnia az otthont adó operációs rendszerhez és ki kell 
tudnia használni annak képességeit a nagyobb teljesítmény 
érdekében. 

A montreáli Open Systems laborban (Ericsson Kutatóinté- 
zet), 2001-ben indítottuk az általános megoldást kereső 
Asynchronous Event Mechanism (AEM) projektet. Az AEM 
segítségével az alkalmazás bizonyos eseményekhez vissza- 
hívható függvényeket adhat meg illetve regisztrálhat, 

az operációs rendszer pedig az események létrejöttekor 
aszinkron módon hajtja végre ezeket. 

Az AEM a fejlesztéshez esemény elvű megközelítést kínál. 
Ezt egy természetes felhasználói csatolófelület bevezetésé- 
vel értük el, ahol az eseménykezelők paraméterlistájában 

a végrehajtásukhoz szükséges és a rendszermagnak közvet- 
lenül elküldendő valamennyi adat megtalálható. 

Az AEM másik mozgatórugója az a tény adta, hogy a több- 
szálú rendszereken futó összetett megoszló alkalmazásokat 
a kezelő réteg miatt általában igen nehéz több rendszerre 
fejleszteni vagy azokra átírni. Az AEM nem pusztán a prog- 
ramfejlesztési idő csökkentését célozza meg, hanem a for- 
ráskód létrehozását is leegyszerűsíti, ezáltal megnövelve 

a különböző rendszerek közti a hordozhatóságot és meg- 
hosszabbítva a program életciklusát. 

A projekt legnagyobb kihívása egy olyan rugalmas keret- 
rendszer tervezése és kifejlesztése volt ahol a futó rendszer- 
ben eseménykezelő megoldásokat tudunk frissíteni és elhe- 
lyezni. Alapkövetelmény volt, hogy a rendszerkarbantartás 
a rendszer újraindítása nélkül is elvégezhető legyen. Az 
AEM moduláris felépítésének köszönhetően rendelkezik 
ezzel a képességgel. 

Az AEM más figyelmeztető mechanizmusok mellett kiegé- 
szítő lehetőségként működik. Az egyik nagy előnye, hogy az 
eseményvezérlet kódot keverhetjük a többi, soros kóddal. 


AEM: Szerkezeti áttekintés 
Az AEM magmodulbál és a köré épülő betölthető modulok- 
ból áll amelyek az adott eseményszolgáltatást nyújtják az 
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1. ábra Az AEM az alapvető eseményfunkciókat 
biztosító magmodulból és az alkalmazásoknak aszinkron 
eseményszolgáltatásokat nyújtó független 
rendszermag modulokból áll 


alkalmazásoknak. Ilyen például a szoftveres időzítés és az 
aszinkron TCP/IP socket csatolófelület (1. ábra). Ez a rugal- 
mas szerkezet lehetővé teszi, az AEM képességeinek tetszés 
szerinti bővítését. 

A modulok által végrehajtott feladatokat száma korlátlan, 
ugyanis saját, független pszeudo rendszerhívás készletüket 
adják át az alkalmazásnak. Iulajdonképpen így akár két kü- 
lönböző modul is szolgálhat azonos feladatokat. Érdekes 
módon éppen ez teszi lehetővé, hogy a továbbfejlesztett 
változatot a többi alkalmazás zavarása nélkül a rendszerbe 
illesszük — azok ugyanis továbbra is a régi verziót használ- 
ják. A felépítés lehetővé teszi, hogy az alkalmazások igénye 
szerint töltsük be az AEM modulokat vagy futásidőben fej- 
lesszük a modulokat. 

Az ilyesfajta rugalmasság előfeltétele, hogy a rendszermag 
stratégiai pontján eseményaktiválási pontokat helyezzünk 
el (2. ábra). Minden aktiválási pont egy-egy eseményeket in- 
dító AEM sornak felel meg. A következő részben az AEM 
belső működését részletezzük. 


AEM: Belső szerkezet 

Az aszinkronitás elve akkor okoz komoly gondot, amikor 

a program végrehajtás fő folyama az eseménykezelők alkal- 
mazásakor figyelmeztetés nélkül megszakad. A bemenetei 
kérelmeket a korábbi bemeneti állapot nélkül kell kezelni. 
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2. ábra Az AEM esemény aktiválási és alkalmazás- 
értesítési szerkezete. Az alvó munkafolyamatokat tartalmazó 
esemény-várakozási sorokat folyamatosan pásztázzuk. 
Az adott esemény bekövetkeztekor valamennyi érintett 
feladat felébred. Ezt követően valamennyi ide tartozó 
folyamathoz rendelt eseményt elindítjuk. 


Ezeket közvetlenül a rendszermag vagy a megszakítás- 
kezelő küldi és fogadásukkor nem feltételezhetünk semmi- 
lyen sorrendet. Ez a helyzet bizonyos alkalmazásoknál 
problémákat okozhat, különösen amelyek TCP/IP alapon 
működnek, hiszen ezek működéséhez fontos ismerni 

a tranzakció állapotát. 

Az AEM három rétegű szerkezetét az eseménykezelést vég- 
ző pseudo-rendszer hívások, az esemény sorosítást kezelő 
és a felhasználói visszahívások érdekében környezetinfor- 
mációkat tároló folyamatonkénti event. struct struktúrák 
valamint az eseményaktiválásért felelős eseményenkénti 
job struct szerkezetek alkotják. 


Események 

Az AEM szemszögéből nézve, az esemény olyan rendszer in- 
ger, amely kiváltja az esemény kezelője, azaz a végrehajtó 
ügynök létrehozását. Ehhez az esemény regisztrációjakor lét- 
rehozott event. struct struktúra nyújt segítséget, amely egy 
esemény kezelő végrehajtásához szükséges környezetet tar- 
talmazza. A legfontosabb mezői a felhasználói tér eseményke- 
zelőire hivatkozó mutatók, azok konstruktorai és destruktorai 
valamint kapcsolatuk más eseményekkel (listaesemények, 
gyermek események és aktív események - lásd a 3. ábrát). 
Folyamatonként annyi regisztrált eseménykezelőt készít- 
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3. ábra A folyamatok és eseményjlistáik közötti kapcsolat 


hetünk amennyi csak szükséges. Amikor az eseményt 
észleljük, azt aktiválódásnak nevezzük és hamarosan meg- 
hívjuk a felhasználó által megadott kezelő függvényt. 

Az események érkezési sorrendben jegyződnek fel a rend- 
szerben. Innentől fogva már az eseménykezelő konstrukto- 
rának feladata az adatokat helyesen kezelni és bármiféle 
sorrendiség feltételezése nélkül sorosítani az egyes folya- 
matokhoz tartozó eseményeket. 

Bizonyos folyamatesemények aktívak és aktív esemény- 
listához csatlakoznak. Aktiváláskor az esemény folyama- 
tot hozhat létre. Ezeket az eseményeket klónozóknak 
nevezik. Az események és az általuk létrehozott folyama- 
tok közti kapcsolatot belsőleg tároljuk. A harmadik ábrán 
megfigyelhetjük a legfelső folyamat által regisztrált ese- 
ményt amely két új folyamatot készített. Ezek az ese- 
ményhez kapcsolva maradnak és saját eseménylistával 
rendelkeznek. 

Az eseménykezelőket az esemény regisztrálásakor hasz- 
náljuk és a felhasználói szinten kell megvalósítani őket. 
Megadhatják saját, előre meghatározott számú paraméte- 
rüket, hogy az esemény adatok közvetlenül a felhasználói 
térben futó folyamathoz kerülhessenek. Ezt a műveletet 

az esemény konstruktorok és destruktorok végzik amelye- 
ket közvetlenül a kezelők előtt és után hívunk meg. 
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4. ábra Periodikus és reaktív munkafolyamatok állapotátmeneti 
grafikonja 


Az eseménykezelők ugyanabban a környezetben futnak 
mint a meghívó folyamat. A mechanizmus biztonságos 

és többszörösen bejárható (re-entrant); a jelenlegi végre- 
hajtás mentésre kerül, végül helyreállítjuk a megszakítás 
előtti állapotot. 

A regisztráció során minden eseményhez valamilyen 
fontossági szintet rendelünk amely a megfelel annak a se- 
bességnek mellyel az alkalmazás az adott figyelmeztetést 
fogadni kívánja. Ugyanazon eseményre két különböző 
fontossági szinten is jelentkezhetünk. 

Más valós idejű figyelmeztetési megoldások, például 

a POSIX jelzések valós idejű kiterjesztése, az ütemezési 
döntés során nem veszik figyelemebe a fontossági szinte- 
ket. Pedig ez fontos, hiszen így a nagy fontosságú esemé- 
nyeket fogadó folyamatokat a többi folyamat előtt tudjuk 
végrehajtani. AEM alatt az esemény megjelenése a fon- 
tossági sorrendnek megfelelően váltja ki a kezelő vég- 
rehajtását. Bizonyos szemszögből, az eseménykezelő fo- 
lyamatnak tekinthető, hiszen van végrehajtási környeze- 
te. A folyamat fontosságok dinamikus változtatása akkor 
okoz igazán komoly gondot, amikor az események beér- 
kezési sűrűsége nagy, hiszen a fontossági szintek ugyan- 
ilyen ütemben változnak. Ezt a problémát az esemény 
fontosságok összességéből számított dinamikus valós 
idejű érték bevezetésével oldottuk meg. Ez az érték 

a Linux ütemező befolyásolása nélkül módosítja az üte- 
mezési döntéseket az alkalmazásoknak pedig valós idejű 
érzékenységet ad. 


Munkafolyamatok 

A munkafolyamat (job) egy új rendszermag fogalom amelyet 
az események figyelmeztető folyamatokat megelőző kiszol- 
gálása érdekében hoztak létre. Ez nem folyamat, bár mind 

a kettő a végrehajtható elem elképzelésen alapul. A munka- 
folyamatok által végzett egyik tipikus feladat, hogy elhelyezi 
magát egy várakozási sorban és itt marad, míg valami fel 
nem ébreszti. Ekkor gyorsan elvégez valami hasznos dolgot, 
például ellenőrzi az adat hitelességét vagy elérhetőségét 

a felhasználói esemény meghívása előtt, majd ismét elalszik. 
A munkafolyamat azt is garantálja, hogy mialatt valamilyen 
erőforrást elér, más munkafolyamatok azt nem érhetik el. 
Egy folyamathoz több munkát is rendelhetünk, de esemé- 
nyenként csak egy munkafolyamatunk lehet. 

Ez a rendszermag és a felhasználói folyamat közötti elvo- 
natkoztatási réteg nélkülözhetetlen. Nélküle igen nehéz 
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A mag által kezelt fizikai memória 


A mag által kezelt virtuális memória 
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. Folyamatok szegmensei 


5. ábra A vmtable felépítése 


lenne biztosítani a konzisztens adat elérhetőség ellenőrzést 
vagy a kezelő végrehajtása során azonos eseményekből 
többet felhalmozni. Amennyiben valami probléma adódik, 
a folyamat a felhasználói térben pazarolja az esemény keze- 
lésére szánt időt. Az, hogy összevonunk-e több figyelmezte- 
tést általában eseménytől függő és az aktiválás előtt kell 
végrehajtanunk. 

A munkafolyamatok általános megvalósításánál figye- 
lembe kell vennünk a megszakításokat, hogy az esemény 
bekövetkezése és a folyamat figyelmeztetése közt lehető- 
leg kevés idő teljen el. Célunk, hogy a folyamatok oldalán 
végezzük el a műveleteket miközben egy megszakítás- 
kezelő és egy rendszermag szál képességeit biztosítjuk, 
mindezt anélkül, hogy a teljes végrehajtási környezetet 
magunkkal hurcolnánk. 

Két típusú munkafolyamatot alkalmaztunk, a periodi- 
kus és a reaktív munkafolyamatokat. A periodikus 
munkafolyamatokat adott időnként, a reaktív munkafo- 
lyamatokat szórványosan, az események észlelésekor 
hajtjuk végre. A munkafolyamatokat saját ütemező 
ütemezi. A valós idejű ütemezés elméletet szerint mind 

a két fajta munkafolyamatot azonos ütemezőnek kell 
forrásokban). A mi környezetünkben a munkafolya- 

mat nem preemptív feladat. definíció szerint a felada- 
toknak nincs megadott határidejűk, bár alacsony szintű 
jellegükből következően végrehajtási idejük közvetetten 
mégis kötött. Ez a feltételezés leegyszerűsíti a megvaló- 
sítást. Esetünkben előfeltétel, hogy a reagáló munkafo- 
lyamatok két meghívás között elhanyagolható idő alatt 
hajtódjanak végre hogy helyt álljanak folyamátviteli 
helyzetekben is. 

A mi megoldásunk a reagáló és a periodikus esetben is 
eltérő, hogy a szórványos események esetében jobb átviteli 
eredményt érjünk el. 

A periodikus munkafolyamatokat a feladatkiosztó 

(job dispatcher) kezeli, a reagáló feladatok ugyanakkor 
teljesítmény megfontolások miatt saját maguk állítják 
állapotukat. A 4. ábra mutatja be a munkafolyamat álla- 
potváltozásokat és az egyik állapotból másikra való 
áttéréshez használt függvényeket. 
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Nyitott kapcsolatok száma 


6. ábra AEMhttpa, egy szálú HITP kiszolgáló amelyet 
az AEM belső megvalósításának skálázhatósági 
tesztjénél használtunk. Minden mintában 100 aktív 
kapcsolatot használtunk. 


Amint a munkafolyamat aktivizálta a megfelelő eseményt, 
vagy aszinkron módon végrehajtunk egy folyamatot vagy 
a felhasználói program jelenlegi futását irányítjuk át a kód 
másik részére. A felhasználó regisztráláskor dönti el melyik 
változatot szeretné alkalmazni. 


Folyamat aszinkron végrehajtása 

Az eseménykezelők végrehajtásához megtörhetjük a fő 
szál végrehajtását vagy létrehozhatunk egy új folyamatot 
amelyben az esemény párhuzamosan futhat le. Az ese- 
mény mindkét esetben átlátszóan és aszinkron módon 
fut, és közvetlenül önállóan felügyeli saját tutó példánya- 
it. Ennek a megoldásnak van néhány fontos következmé- 
nye ugyanis az alkalmazásnak nem kell idő előtt megőriz- 
nie vagy elhasználnia a rendszer erőforrásait. Próbakép- 
pen az AEM teljesítményméréséhez készítettünk egy 
egyszerű HTTP kiszolgálót, amely teljesen egyszálú és 

az ilyen típusú kiszolgálókhoz képest meglehetősen jó 
teljesítményű. Cikkünk végén mutatjuk be. 

Néha előfordulhatnak olyan helyzetek, amikor az ese- 
mény megválaszolásához kénytelenek vagyunk új folya- 
matot létrehozni. Sajnos a folyamat dinamikus létrehozá- 
sa elég erőforrás-pazarló; ez alatt az időszak alatt sem az 
új sem a szülő folyamat nem képes új kérelmeket kezelni. 
Bizonyos kritikus helyzetekben, például a rendszermemó- 
ria betelésekor elképzelhető, hogy nincs erőforrás ilyen 
célra. Ez azért komoly probléma mert a vészhelyzetben 
szükségünk lehet új folyamatok létrehozására amelyek 
figyelmesen zárják le a rendszert vagy hívásátadó proce- 
dúrákat hajtanak végre. 

A probléma orvoslására bevezettük egy új, kapszulának 
nevezett modellt. A kapszula olyan előre beállított folya- 
mat struktúra amely az egyéb üres kapszulákat tároló 
tárolóban található. Amikor a folyamat új végrehajtási 
környezetet akar létrehozni, a kapszulát kicsatoljuk a táro- 
lóból és a jelenlegi folyamat néhány paraméterével alap- 
helyzetbe állítjuk. 

A esemény regisztráláskor külön jelek mutatják hogy 

a kezelőt a folyamaton belül kell-e végrehajtani. Ha nem 
adunk meg paramétert vagy 0-t adunk meg akkor a keze- 
lót a folyamat futásának megtörésével kell végrehajtani. 
A jelek a következők: 


www.linuxvilag.hu 











e. EFV FORK: a folyamatot a forkO hívással azonos 
formában kell elvégezni. 


e. EVF CAPSULE: a folyamatot a kapszula tárolóból 
vesszük. 


e. EVF NOCLDWAII: ennek a jelnek a SIG NOCLDWAIT 
jelzéssel azonos jelentése van. Amennyiben létezik 
gyerek folyamat, új szülőt kap a kapszulakezelő szál 
személyében. 


e. EVF KEEPALIVE: megakadályozza a folyamat/kap- 
szula kilépését azáltal, hogy belép egy rendszermag 
ciklusba (a while(1) utasításhoz hasonlóan) csak 
felhasználói térben. 


Memóriakezelés 

Az esemény vezérelt rendszerekben igen fontos kér- 
dés a memóriakezelés, hiszen az eseményeket közvet- 
lenül a rendszermagtól származó alkalmazástérben 
található visszahívási függvények kezelik. A legegysze- 
rűbb megoldás az lenne, ha csak akkor foglalnánk le 

a memóriát amikor a folyamat jelentkezik az eseményre. 
Ugyanakkor gondoljunk bele, mi történik ha rengeteg 
eseményt kell regisztrálni, vagy ha olyan folyamataink 
vannak amelyeket újra kell indítani, új eseményeket 
kell hozzájuk adni, esetleg eseményeket kell eltávolíta- 
nunk. Amennyiben az eseménykezelésben hiba történik, 
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a rendszerintegritás sérül. Kevésbé veszélyes az operáci- 
ós rendszer számára, ha az ilyen erőforrásokat maga 
kezeli és a memóriát a folyamatok igénylése szerint 
dinamikusan foglalja le. 

Teljesítmény szempontból ezt a memóriát egy előre lefog- 
lalt tárhelyből kell kiosztanunk, hogy elkerüljük a me- 
mória feldarabolódását és fenntartsuk a valós idejű jel- 
lemzőket. Az általános célú memória foglaló eljárások 
mint a glibc mal locO) függvényei, bár általános célokra 
jól is használhatóak, nem igazán felelnek meg ezeknek 
a követelményeknek. 

Néhány adattípust, például az egészeket, könnyedén át 
tudjuk adni a felhasználói térbe, az olyan összetettebb adat- 
típusok viszont mint a karaktersorozatok, már külön meg- 
valósítást igényelnek. A folyamatok memóriakezelését 

a glibc könyvtár végzi. A dolgok bonyolódnak ha a rend- 
szermagtól szeretnénk memóriát foglalni, mivel arra is 
ügyelnünk kell, hogy az újonnan lefoglalt memóriaterület 
jó helyen legyen és a folyamat térben helyezkedjen el. 

A felhasználói térből elérhető egyszerű és hatékony me- 
móriafoglalás egyelőre hiányzik a rendszermagból, pedig 
szükség lenne rá. 

Az AEM ovmtable megoldása ezt a memóriafoglalási hiá- 
nyosságot próbálja orvosolni. A ,binary buddy allocator" 
egyik változatát valósítja meg (Knuth után, lásd a forráso- 
kat) a felhasználói folyamat memória tárán keresztül. 
Ennek segítségével majdnem bármilyen előre nem terve- 
zett méretű és típusú adat kezelése megoldható. Kritikus 
memóriahiány esetén a eseménykezelőkön keresztül a fel- 
használóra bízza döntést. E képesség segítségével végső 
megoldásként visszanyúlhatunk glibc változathoz 
amennyiben valami baj történne. 


2005. január 11 





SZTN 


0 Kiskapu Kft. Minden Jog fenntartva 


Az AEM úgy készült, hogy amennyiben van még sza- 
bad blokk, konstans idő alatt adjon vissza érvényes mu- 
tatót. A tlekommunikációs alkalmazások esetében ame- 
lyek valószínűleg azonos méretet igényelnek azonos al- 
kalmazástípus esetén, általában éppen ilyesmire van 
szükség. A rövid idő alatt érkező és különböző méretű 
kérelmek által okozott memória töredezettséget is meg 
szerettük volna előzni. 

A vmtable egy érdekes kiterjesztéssel is rendelkezik: 
felhasználói térből készíthetünk vele alaphelyzetbe 
állító függvényeket az eszközmeghajtókhoz. Ezt egy 
mutató használatával tehetjük meg, amelyet az AEM 
alrendszer segítségével a rendszermagtól foglaltunk 

és visszahívott függvény által adtuk át a felhasználói 
folyamatnak. A függvény visszatérésekor a terület 
visszakerül a rendszermaghoz. A visszahívott függvé- 
nyek nem csak események kezelésére jók, hanem nagyon 
jól használhatóak a rendszermaggal történő biztonságos 
kapcsolattartásra is. 

Ebben a felállásban minden felhasználói folyamathoz 
rendelünk egy memóriaterületet, amit vmtable-nek ne- 
vezünk. Az elágaztatott (forked) folyamatok és kapszu- 
lák vmtable-je szülőfolyamatuk omtable táblája alapján 
automatikusan öröklődik. Két különböző stratégiát 
alkalmazunk: 


1. VMT. UZONE: a foglalást a folyamat heap szegmens- 
égben hajtjuk végre. Ez ugyan gyors elérést tesz 
lehetővé, de a felhasználói folyamat memóriahelyét 
fogyasztja. 


2. VMT. VZONE: A foglalást a rendszermag címterében 
végezzük, majd belapozzuk a folyamat címterébe. 
Ezzel minimális memóriafogyasztást érhetünk el, 
de a laphibák kezelése miatt a folyamat több időt 
vesz igénybe. 


Mindkét eljárásnak helyzettől függően vannak előnyei 
és hátrányai. A kívánt stratégiát az alkalmazás indítása- 
kor, futásidőben választhatjuk ki. Az 5. ábra a vmtable 
szerkezetét mutatja be. 

A jelenlegi megoldásban a vomtable alrendszer köz- 
vetlenül fizikai lapokat foglal le. Ez azért van így, 
hogy a foglalások biztosan folyamatosak legyenek és 

a memóriát biztonságosan használhassák az [/D műve- 
letek. A jövőben hálózati teljesítmény terén is szeret- 
nénk közvetlen ki-/bemenetere felhasználni a vmtable 
rendszert. 

A vmtable egyszerű és könnyen kezelhető felületet nyújt 
az AEM felhasználóknak és modulfejlesztőknek, a me- 
móriafoglalás összetettségét a rendszermag térbe rejtve. 
Az átlátszóság kedvéért az ABEM magmodulba egyszerű 
memúóriafoglalási és felszabadítási rutinokat építettünk. 
Ez a csatolófelület nagyban leegyszerűsíti a modulok 
karbantartását és átvitelüket a különféle Linux rendszer- 
mag kiadásokra. 


ökálázhatóság 


Végeztünk egy tesztet, hogy megtudjuk miképpen visel- 
kedik az AEM két távoli folyamat között zajló egyszerű 
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adatcsere közben. A teszt fő célja annak kiderítése volt, 
hogy a eseménykezelő környezetváltása miatt fellépő 
időveszteség nem okoz-e teljesítmény problémákat. 
Mostanában elvégeztünk egy teljesítménytesztet is amely 
az AEM skálázhatóságát tette próbára valamint ellenőrizte 
az AEM magvát alkotó munkafolyamatok és várakozási 
sorok belső megvalósítását. 

Könnyen összehasonlítható számokat keresve, úgy döntöt- 
tünk, hogy egy már létező webkiszolgálót keresünk és azt 
alakítjuk az AEM csatolófelületéhez. Az AEMhttpd egysze- 
rű, egy szálon futó HITP kiszolgáló (lásd a forrásokat.) 

Az egyszálú kiszolgáló teljes egészében a folyamat fő végre- 
hajtási szálában fut. Azaz nem hozunk létre sem felhaszná- 
lói sem rendszermag szálakat a HTTP kérelmek kezelésére. 
A méréseket ilyen típusú kiszolgálóval végeztük és inkább 
a megvalósításra semmint a kiszolgáló tényleges teljesítmé- 
nyére koncentráltunk. 

A 6. ábrán bemutatott példán 100 aktív tranzakciót futtat- 
tunk. Minden tranzakcióban megnöveltük a nyitott kapcso- 
latok számát ezzel megnövelve a munkafolyamatok számát 
a socket kapcsolat várakozási sorában. A select -en ala- 
puló hagyományos megoldásban ez megnövelte volna 

a kérelmekre adott válaszidőt, hiszen a leírókat a rutin 
sorban nézné végig. Az AEM alkalmazásával azonban 

csak az aktív munkafolyamatok (azaz a kész adatot tartal- 
mazó socketek) hajtják végre a megfelelő eseménykezelői- 
ket. Ezzel a módszerrel az AEM képes általános és skáláz- 
ható megoldást nyújtani. 


Osszefoglalás 

Az iparban széles körben használják a Linuxot, amely 
büszkén nevezheti magát vállalati szintű megoldások 
választott operációs rendszerének. Nem jár messze attól 
sem, hogy a következő generációs IP-alapú telefonszolgál- 
tatások választott operációs rendszerévé váljon. A Linux 
képességeit ma már széles körben elismerik, de a skálázha- 
tóságot, teljesítményt és megbízhatóságot váró, következő 
generációs szolgáltatókat a rendszermag szinten végezett 
fejlesztések fogják leginkább vonzani. 

Az AEM erőteljes próbálkozás az aszinkron folyamat- 
értesítés és esemény adatkiegészítés terén. Segítségé- 
vel kihasználhatjuk az esemény vezérelt programozás 
előnyeit, amely biztonságos alkalmazásfejlesztést tesz 
lehetővé. Ezen felül az AEM olyan részeket is tartal- 
maz, melyek célja az alkalmazás megbízhatóságának 

és hordozhatóságának növelése könnyen kezelhető 
felülete révén. 


Köszönetnyilvánítás 

Köszönet az Open Systems Lab összes kutatójának az 
Ericsson-tól pedig Lars Hennert-nek hasznos tanácsaikért, 
valamint az Ericsson Research-nek, hogy jóváhagyta e cikk 
megjelenését. 


Linux Journal 2004. november, 127. szám 


Frédéric Rossi (Frederic.Rossi(Dericsson.ca) 

Az Ericsson Research Open Systems Lab fejlesztője 
Kanadában, Montreál városában. Az AEM atyja és 

a fejlesztés vezetője. 


Linux és RTAl Automaták épitéséhez 


Ez a könnyen telepíthető, web-alapú vezérlőrendszer szabványos telefon vezeté- 
keket használ és bármely távirányítóval rendelkező egységet képes kezelni. 


ikkünkben egy olyan, az épületekben található kü- 
c lönféle légkondicionáló berendezések központosí- 

tott működtetését végző vezérlőrendszer fejleszté- 
séről és tervezéséről írunk, amelyet Linux illetve valós idejű 
Linux alkalmazás csatolófelület (RTAI) segítségével hoztunk 
létre. Az épületben elszórtan elhelyezkedő légkondicioná- 
lók saját infravörös távirányítóval rendelkeznek. Célunk az 
volt, hogy a légkondicionálók vezérlését központosított, 
számítógéppel vezérelt megoldással váltsuk fel, amely ké- 
pes ki- és bekapcsolni a készülékeket, valamint a kívánt hő- 
mérsékletet és fordulatszámot beállítani. A projekt ötlete 
akkor merült fel, amikor a helyi egyetemnek, szerény keret- 
ből megvalósítható, központosított és rugalmas a légkondi- 
cionáló vezérlési megoldásra volt szüksége. Hasonló célok- 
ra léteznek üzleti alkatrészek és programok, de általában 
túlságosan költségesek és gyártófüggőek. 
Projektünk alkatrész megvalósítása egy Linuxot futtató 
központi vezérlő-számítógépből és a hozzá csatlakoztatott 
RS-485-ös mikrovezérlő hálózatból áll. A mikrovezérlők 
a közeli felszereléseket irányító infravörös jelekkel paran- 
csokat tudnak küldeni a megfelelő légkondicionálónak. 
A rendszer programterve két valós idejű feladatot (a fő ve- 
zérlő feladatot és a RS-485 hálózat vezérlő feladatot) vala- 
mint további, nem valós idejű feladatokat (a webkiszolgálót 
és az adatbázist) tartalmaz. A felhasználói felületért a web- 
kiszolgáló felel így az egyetem számítógép-hálózatán bár- 
mely böngészőről elérhető. Adataink tárolására a PostgreSOL 
adatbázist választottuk. Megvalósításunk olyan alacsony 
költségű megoldás, amely igény szerint rugalmasan bővíthe- 
tő. Ezen kívül gyártófüggetlen és bármely légkondicionálóval 
működik, amely képes infravörös távirányítót kezelni. Vala- 
mennyi légkondicionáló önállóan működik, saját hőmérsék- 
let-vezérlő rendszerével. Az eszközök működésének ellenőr- 
zésére a hálózat valamennyi mikrovezérlőjét hőérzékelővel 
láttuk el amely regisztrálja az aktuális teremhőmérsékletet és 
jelenti a központi számítógépnek. 


Felhasználói felület 

A teljes felhasználói felület weblap alapú. A kezdőlapon az 
összes légkondicionáló állapotának összefoglalóját soroljuk 
fel. A megjelenített adatok között találjuk a légkondicioná- 
lót azonosító szöveget, az épületben elfoglalt helyét, a jelen- 
legi trremhőmérsékletet valamint, hogy van-e az eszköznek 
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1. ábra A vezérlőfelületről a hitelesített felhasználó beindíthatja 
a légkondicionálót, új hőmérsékletet állíthat be vagy kikapcsolhatja azt 


valamilyen előreprogramozott működési módszere, amely 
alapján éppen dolgozik. Erről a lapról valamennyi légkon- 
dicionáló külön kezelőfelületére mutat egy-egy hivatkozás. 
Mielőtt erre a lapra juthatnánk, a rendszer felhasználónevet 
és jelszót kér. Ezen a szinten lehetőségünk nyílik utasításo- 
kat adni a rendszernek, közvetlenül vezérelni a légkondici- 
onálót illetve megváltoztatni vagy létrehozni az automati- 
kus működés valamilyen programját (1. ábra). 

A rendszer legérdekesebb része a programozott működés. 
Például a rendszer képes az órák kezdete előtt minden nap 
automatikusan bekapcsolni a a légkondicionálókat, minden 
szobában előre megadott hőmérsékletértékekkel. Aztán es- 
te, amikor már nincs élet az épületben vagy az adott terem- 
ben, a rendszer lekapcsolja a légkondicionálókat. 


Alkatrész felépítés 

Az alkatrészkészlet a központi számítógépből és a légkondi- 
cionáló gépeket irányító mikrovezérlőkből áll. Valamennyi 
mikrovezérlőt RS-485 kéteres hálózatra kapcsoltuk. Megva- 
lósításunkban az Intel származék ATMEL A189C2051-es 
jelzésű vezérlőt alkalmaztuk. Húsz lábú DIP csomagban 
kapható, 128 byte adat memóriával és 2XKXB ROM kód 
hellyel, egy aszinkron soros kapuval és 14 független digi- 
tális [DO kapuval rendelkezik. 
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A mikorvezérlő lapját és elemeit a 2. ábrán mutatjuk be. 

Az infravörös jeleket a mikrovezérlőben található program 
hozza létre az egyik digitális kimeneti kapu segítségével. 

A soros kapu kapcsolja a mikrovezérlőt az RS-485 hálóza- 
tunkhoz. Valamennyi mikrovezérlő lapot felszereltük 

a Dallas Semiconductor DS1620 típusú hőmérőjével. 

A mikrovezérlő 3 eres, digitális szinkron soros felületen 
kommunikál a hőérzékelővel. A mikrovezérlőben nincs al- 
katrész szintű támogatás a szinkron soros felület kezelésé- 
hez, ezért a vezérlést programozottan oldottuk meg a nor- 
mál [/DO kapukon keresztül. 

Alkalmazásunkban azért esett az RS-485 hálózatra a válasz- 
tás, mert könnyen telepíthető, olcsón megvalósítható és 
könnyen összekapcsolható vele hasznos mennyiségű cso- 
mópont. A csomópontokat mindössze egyetlen 3-as kate- 
hajtó korlátai miatt a lehetséges csomópontok száma 32, de 
ezt a számot könnyedén megnövelhetjük hálózati ismétlők 
segítségével. A vezérlő-számítógép és az első ismétlő, vagy 
két ismétlő közötti maximális kábelhossz 1200 méter. 

A fizikai kábel elérést mester-szolga elven vezéreljük. 

A Linuxot futtató számítógép a mester, amely előre megha- 
tározott sűrűséggel kérdezi le a csomópontokat. A mester 
minden lekérdezéskor parancsot küld a csomópontnak; 

a lekérdezett csomópont adattal válaszol a mesternek avagy 
üres csomagot küld, jelezve, hogy a csomópont élő. Az 
ilyesfajta élérési megoldás hátrányára akkor derül fény, 
amikor a mester áll le. Ilyenkor ugyanis a teljes hálózat is 
csődöt mond. 

A mikrovezérlők korlátozott számát figyelembe véve a 9. bit 
protokoll segítségével állapíthatjuk meg, hogy a hálózaton 
átküldött csomag az adott vezérlőhöz tartozik-e. A hálóza- 
ton átküldött minden egyes bájthoz tartozik egy 9. bit is. 

Ez a kiegészítő bit kizárólag a csomag cél cím esetében 

lesz magas rétékű. A mikrovezérlő UART (universal 
asynchronous receiver and transmitter) alapértelmezés sze- 
rint csak akkor vált ki megszakítást, ha a fogadott érték 

9. bitje magas. A megszakítás szolgáltatás rutinja ezután 

a fogadott bájtot összehasonlítja a csomópont címével. 
Amennyiben megegyeznek, a megszakítás átprogramozza 
az UIART-ot, hogy a 9. bit állapotától függetlenül, vala- 
mennyi bájtot fogadja a csomag végéig. Amennyiben a cél 
címe nem egyezik meg a csomópont címével a megszakítás 
rutin visszatér. 

A központi számítógép UART-ja, lévén PC alkatrész, nem 
támogatja közvetlenül a 9. bit protokollt. E hátrányt a meg- 
hajtó a paritás bit segítségével szimulálva próbálja meg ki- 
küszöbölni. A bájt átvitele előtt a meghajtó úgy állítja be 

a paritást, hogy a cím bájtok esetében egy legyen a többi 
bájt esetében pedig nulla. 

A 3. ábra a rendszer feladatait és a köztük élő kommunikáci- 
ós vonalakat mutatja be. 


Valós idejű feladatok 

A fő vezérlő feladat, a a hálózati elérést vezérlő feladat és 
az RS-485 hálózat fizikai rétegének program meghajtója 
valós időben futó feladatok. Az RTAI-hoz kifejlesztettünk 
egy RS-485 meghajtóját. A meghajtó az alkalmazásban fel- 
használt és korábban bemutatott 9. bit protokoll kivételével 
hasonló a többi soros meghajtóhoz. 
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2. ábra A mikrovezérlő lapja a mikrovezérlő eltávolítása után 
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3. ábra A rendszerfeladatok közötti kommunikáció 


A másik valós idejű feladat a hálózati elérést vezérlő 
feladat, mely meghatározott időnként csomagokat küld 
az egyes hálózati csomópontoknak. A csomag lehet az 
infravörös jelet bekapcsoló parancs vagy lekérdezés ami- 
vel kideríthetjük, hogy a csomópont aktív-e, valamint az 
aktuális tremhőmérsékletet lekérdező parancs. Az első 
két csomagtípus esetében a csomópont visszaigazolással, 
az utolsó esetében a teremhőmérséklettel válaszol. A fő 
vezérlő folyamat valamennyi csomópont aktuális állapo- 
tát ismeri, és értesíti a felhasználói felületet ha valamelyik 
csomópont meghibásodott. 

A fővezérlő feladat, az adatbázisban tárolt, előre prog- 
ramozott információk alapján működteti az épület lég- 
kondicionáló berendezéseit. A faladat képes parancsokat 
fogadni a felhasználói felületről, amelyek két RT-FIFO 
segítségével felülbírálhatják az előreprogramozott beállí- 
tásokat. Az RT-FIFO folyamatközi kommunikációs ruti- 
nok feladata a valós idejű és normál Linuxos feladatok 
párbeszédének lehetővé tétele. A PostgreSOL adatbázis- 
sal való kommunikációhoz Linux démont kellett kifej- 
leszteni. A démon két másik RI-FIFO csatornán keresz- 
tül beszélget a fővezérlő folyamattal. A démon másik 
fontos feladata a rendszer időt és dátumot elküldeni 

a fővezérlőnek, ugyanis ennek kiolvasására nem létezik 
megoldás RIAI alatt. 





4. ábra A teljes mikorvezérlő lap a telepítés után 


A kifejlesztett rendszer parancsokat küld a légkondicioná- 
lóknak, így nincs szükség helyi távirányítókra. A légkondi- 
cionálók hőszabályzó rendszerébe nem avatkoztunk bele 
és nem változtattuk meg a belső kapcsolási sémákat sem. 
Minden légkondicionáló saját beépített hőszabályzó rend- 
szerét használja, a mikrovezérlőkbe épített hőérzékelők 
pedig ellenőrzik, hogy az eszköz helyesen működik-e. 


A 4. ábra a telepített mikrovezérlőt mutatja be. 


Linux feladatok 

A Linux feladatok célja a felhasználó felület megjeleníté- 
se a fő adatforrásként használt PostereSOL adatbázis futta- 
tásával a webkiszolgálón keresztül. Mint korábban leírtuk, 
a másik Linux oldali feladat a démon, amelyet a RIAI 
fővezérlő feladat használ a rendszer idő/dátum és az adat- 
bázis eléréséhez. 

A felhasználói felület egyszerű. Az első lapon az egyes lég- 
kondicionálók aktuális állapotát láthatjuk. Ezt a lapot min- 
den felhasználó elérheti. A program megváltoztatásához 
vagy egy adott légkondicionáló utasításához a rendszer fel- 
használói nevet és jelszót kér. Az adatbázisból lekért informá- 
ció dinamikus megjelenítéséhez a PHP nyelvet használtuk. 
A rendszer a PostereSOL adatbázisban tárolja az általános 
információkat (BTU, elhelyezés, márka, mikrovezérlő háló- 
zati azonosító) programozott műveleteket és az egyes kon- 
dicionálók működtetéséhez használt infra parancsokat. 


IRC parancsfelület 

A rendszer fontos eleme az a modul, amely a légkondi- 
cionáló távirányítójának jeleit olvassa be és a megfelelő 
eszközhöz rendelve az adatbázisban tárolja az kapott 
azokat, hogy később a hálózatba kötött mikrovezérlőkkel 
a jeleket újra létre lehessen hozni. Ezt a modult csak 
olyankor használjuk amikor egy új márkájú és/vagy 
vagy eltérő parancskészletű légkondicionálót veszünk 
fel a rendszerbe. 

A modul két részból áll: az első az infra jeleket beolvasó va- 
lós idejű feladat. A hálózati forrásokban felsorolt LIRC Pro- 
jekt valamint a Ripoll and Acosta tanulmány részletes infor- 
mációkat tartalmaz az infravörös távirányítókról. Ugyanitt 
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normál Linux és RT-Linux rendszerekhez készült példaal- 
kalmazásokat is találunk. A modul másik feladata a Linuxon 
futó felhasználói felület. A két feladat RI-FIFO kapcsolaton 
keresztül kommunikál. 

A mikrovezérlőkben használható kis mennyiségű RAM és 

a hosszú infravörös jelhossz miatt, a program fontos funkci- 
ója, hogy segít a felhasználónak megszerezni a különféle 
infra távirányítók gombokhoz vagy gombkombinációkhoz 
rendelt ismétlődő parancsokat. Ezeket a mintákat aztán 

a mikrovezérlő belső programjába (firmware) beégetve 

újra elő tudjuk állítani az eszközt vezérlő jelet. Például 
amennyiben tíz különféle minta létezik, a megfelelő 
mikrovezérlőhöz a hálózaton keresztül küldött parancs 

a következő lesz: ismételd meg az egyes számú jelet tízszer, 
aztán a kettest háromszor és így tovább, míg a teljes paran- 
csot meg nem kapjuk. A technika előnye hogy kevesebb 
erőforrást használ a jel ismételt előállításához. Hátránya, 
hogy valahányszor új légkondicionálót vásárolunk, a mik- 
rovezérlő programját meg kell változtatni, hogy az új esz- 
köz parancskészletét kezelje. 


Költségek 

Jelen pillanatban kilenc légkondicionálót kezelünk a leírt 
rendszerrel; valamennyi ugyanabban az épületben találha- 
tó. Hamarosan további tizenötöt veszünk fel. Az egyes 
mikorvezérlők alkatrészköltsége 60 dollár, a központi vezér- 
lő számítógép költsége 500 dollár. Iovábbi költségek az RS- 
485 hálózat kiépítése és természetesen a rendszer kifejlesz- 
tésének és megvalósításának költsége. 


Osszefoglalás 

A megvalósított rendszer megfelel az aktuális felhasználó 
igényeinek. A projekt sikere miatt az egyetem által vásárolt 
valamennyi további légkondicionálónak együtt kell működ- 
nie a rendszerrel. Ennek egyetlen követelménye, hogy vala- 
mennyi új légkondicionálónak rendelkeznie kell infravörös 
távirányítóval. 

Az RTAI-nak hála a rendszer fővezérlő feladata független 

a Linux alatt futó felhasználói felület folyamataitól. Még 
abban a valószínűtlen esetben is, ha a Linux leállna, a rend- 
szer tovább folytatná az előre beprogramozott műveleteket. 
A jövőben a rendszer könnyedén kiterjeszthető az épület 
világításának, riasztóinak, korlátozott elérhetőségű területe- 
inek és egyéb rendszereinek vezérlésére. 
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Pont-pont kapcsolatok megvalósítása Linux 


segítségével 


Egy pénzügyi cég úgy döntött, felépíti saját redundáns WAN útválasztólt. 
Most megismerhetjük a trükkös részleteket és hogy hogyan Is működik az egész. 


últ nyáron a befektetési cég, amelynél dolgozom 
HAJA úgy döntött, létrehoz egy katasztrófa elhárító he- 
lyet. Itt, New Yorktól 40 mérföldre tükrözné az 
összes Manhattan belvárosában zajló műveletet. Projek- 
tünkben a lehető legtöbb helyen szerettünk volna Linuxot 
használni, mégpedig a következő okok miatt: 
1. Egyébkéntis főként Linuxon dolgozunk, így használhat- 
nánk a meglévő tapasztalatainkat. 
2. letszőlegesen testre szabhatnánk a beállításokat, hiszen 
minden nyílt forráskódú lenne. 
3. Azt reméltük a Linux megoldások olcsóbbak mint más 
cégek, például a Cisco megoldásai. 


Ebben a cikkben azt fogom bemutatni, minként használha- 
tó nagy kiterjedésű hálózatokban (Wide Area Network; 
WAN) a Linux útválasztóként. A WAN útválasztó saját meg- 
határozásom szerint az a rendszer, amely két WAN kime- 
nettel rendelkezik. Ezek lehetnek például 11 és 13 vonalak, 
de az is elképzelhető, hogy a rendszer egy helyi, például 
egy 1I00basel szabványú hálózathoz is csatlakozik és a két 
hálózat közt továbbítja a csomagokat. 


A hálózati megtervezése 

Külön vonalakat vásároltunk, hiszen katasztrófa elhárító 
helyről volt szó, így a lehető legmegbízhatóbb vonalakra 
volt szükségünk. Számításaink szerint egy 13 (45Mb/sec) és 
négy I1 (egyenként 1,544Mb/sec) vonal elegendő sávszéles- 
séget biztosítana a műveleteink számára. Végül a 13-as vo- 
nalat használtuk elsődleges kapcsolatként és a 11-eseket 
meghagytuk kötött 5 7/Mb/sec sebességű kisegítő vonalnak. 
A WAN kapcsolatokat a hálózati tervünk határozta meg. 
Biztosítékként két WAN útválasztót állítottunk szolgálatba 
mindkét oldalon. Az útválasztók azonosak és a I1 és 13 vo- 
nalakhoz egyaránt megfelelő alkatrészekkel rendelkeznek. 
Egy osztóalkatrész beiktatásával szerettük volna az összes 
WAN kapcsolatot az összes útválasztóval összekötni, ahogy 
azt az 1. ábrán láthatjuk. Végül azonban kiderült, hogy ezt 
a megoldást elképesztően nehéz megvalósítani az alább is- 
mertetett nehézségek miatt. 

A WAN csatolásokon felül a távoli gépet a szolgáltatást nyúj- 
tó cég gerincvezetékén keresztül az internethez is csatlakoz- 
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1. ábra Redundáns WAN csatornák 


tattuk. A ,több kapcsolat jobb mint kevés" elvet követtük és 
ez igen hasznosnak bizonyult később a hálózat tervezésénél. 
Amikor az ember egy félregépelt paranccsal véletlenül leál- 
lítja a 13-as vonalat, akkor tudja igazán értékelni, hogy az 
útválasztókhoz beépített egy hátsó ajtót az internet felől. 


Alkatrész igény 

A szolgáltató cégnél egy darab szabványos szekrény hely 
állt rendelkezésünkre. Következésképpen a helyigény el- 
sődleges szemponttá vált, hiszen mi sok kiszolgálót szeret- 
tünk volna telepíteni. Ezért a WAN útválasztóinkhoz 1U 
rendszereket választottunk. Nehéz volt meghozni ezt 

a döntést, hiszen az alkatrészellátással kapcsolatos lehetősé- 
geink így erősen korlátozottá váltak. Visszatekintve sokkal 
egyszerűbb lett volna 2U rendszerként elkészíteni a WAN 
útválasztóinkat. 

A következő lépés a I1 és 13 csatolófelületet biztosító kár- 
tyák kiválasztás a volt. A fő kérdést itt annak eldöntése je- 
lentette, hogy olyan kártyát használjunk-e, amely integrált 
csatorna szolgáltatási egységgel / adat szolgáltatási egység- 
gel rendelkezik (integrated channel service unit/data servi- 
ce unit azaz CSU/DSU) és ezt közvetlenül csatlakoztassuk 
a bejövő WAN körre, vagy egy nagy sebességű soros csat- 
lakozóval rendelkező kártya mellett döntsünk önálló 
CSU/DSU egységgel kiegészítve. Helybéli kötöttségeinket 


figyelembe véve az integrált megoldás tűnt előnyösebbnek. 
Korábbi WAN telepítéseinkben, Cisco 2620-es útválasztó 
dobozokat alkalmaztunk 11 kártyákkal kiegészítve. Ebben 
a projektben azonban ez már nem volt elegendő, hiszen 
több T1 és 13 vonalat szerettünk volna alkalmazni. 

Hosszú keresgélés után egyetlen gyártónál találtunk olyan 
eszközt amely 13 és több 11 kártyát is kezelni tudott, az 
SBE Inc termékét. Az ilyen kártyák piaca nem túl nagy, 

a gyártók sincsenek túl sokan. WAN kártya keresésnél érde- 
mes elkezdeni a technikai támogatást nyújtó részleget kér- 
désekkel bombázni és figyelni, hogyan válaszolnak. Egyút- 
tal figyelmesen olvassuk át a meghajtó és alkatrész adatokat 
mielőtt valamelyik gyártó mellett letennénk a voksunkat. 


Az útválasztók fizikai tervezése 

Az SBE 13-as és a négy 11-es kártyájához két darab teljes 
magasságú, fél hosszúságú PCI helyre volt szükségünk. 
Végül a Iyan 55102 alaplapok mellett döntöttünk egyetlen 
Pentium 4 Xeon 2.4GHz processzorral. Memóriának 256MB 
ECC RAM-ot alkalmaztunk a maximális megbízhatóság 
érdekében. 

A rendszerleállás esélyének minimalizálása érdekében 
Flash-alapú IDE eszközöket alkalmaztunk. A SimpleTech 
cégnél találtunk egy olyan eszközt, amely hagyományos 
merevlemezként csatlakoztatható és vezérelhető. 256MB 
méretű eszközök mellett döntöttünk, mivel úgy véltük ele- 
gendő lesz a Fedora Core 1 működéséhez. 

A teljes számítógéprendszert (a WAN kártyáktól eltekintve ) 
fehér doboz (white box system) forgalmazótól vásároltuk. 
Ez kicsit problémásnak bizonyult, mivel a forgalmazó nem 
volt képes négy teljesen azonos rendszert összeállítani. 

A rendszerek CPU hűtő gyártók és memória sebesség tekin- 
tetében tértek el egymástól. 

Az egyetlen terület ahol a forgalmazó hasznosnak bizo- 
nyult a helyes doboz kiválasztása volt. A számtalan rend- 
szergyártó közül akikkel beszéltem csak egyetlen egy tu- 
dott olyan alaplap doboz kombinációt kínálni amely két 
teljes méretű PCI kártyát képes befogadni. Reméltük, 
hogy a Delltől vagy IBM-től tudunk valamilyen alapgépet 
vásárolni, de egyik nagy név sem tudott a követelménye- 
inknek megfelelni. 


Vezetékek és kábelezés 

Létfontosságú, hogy az irodát több vezeték is összekösse 

a háttérhellyel. Iudjuk meg meg ki szolgáltatja a rendsze- 
rünket és a háttérhelyet több különböző szolgáltatótól ren- 
deljük meg. Irodánk fizikailag két szolgáltatóhoz kapcsoló- 
dik, így végül a 13 vonalat az egyiktől a T1-eseket a másik- 
tól rendeltük meg. Ha nem nézünk utána figyelmesen me- 
lyik szolgáltató rendelkezik tényleges fizikai vonallal a he- 
lyünkhöz, végül úgy járhatunk, hogy valamelyik ponton 
egyetlen gyártó vonalán fut át minden adatunk. 

11-ek szabványos RJ-45 kábeleken keresztül jönnek be. 
Általában a szolgáltató a demarkációs pontnál (demarc) 
fejezi be a 11-eseket — és egyúttal a garancia vállalását is. 

A demarkációs pont általában az a hely, ahová az összes te- 
lefonkapcsolatunk is megérkezik. Ínnen indítva egyszerű 
dolog Ethernet kábeleket vezetni a szekrényhez. 

13-asok már kicsit több odafigyelést igényelnek. A fizikai 
kapcsolat két koaxiális kábelen keresztül történik, az egyi- 
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ken az adás a másikon a vétel. A 13-as RG-59A jelű kábelt 
használ BNC csatlakozókkal. A 13 szolgáltató felhívta a fi- 
gyelmünket, hogy a kiszolgáló termünk túl messze van 

a vevőtől az épületünkben, így 13 ismétlőre lesz szüksé- 
günk. Ez 4U helyet és 120-voltos csatlakozót igényelt 

a szekrényünkben. Szerencsére ez a távolsági probléma 

a társzolgáltatói oldalon nem ismétlődött meg. 


Megosztás és vezetékek 

Az volt a célunk hogy a valamennyi vezetéket az összes 
WAN útválasztóval összekötjük (1. ábra), a tartalék rendsze- 
ren pedig mindkét végen kikapcsolva hagyjuk a őket. 
Mindkét oldalon egy-egy kiszolgáló lenne a TI3 mester, míg 
a másik a 11-eseket szolgálná ki. Ha bármelyik útválasztó 
kiesik, a kört fel lehet hozni a másik útválasztón. 
Kutatásaink, de különösen a Cisco felső kategóriás telekom- 
munikációs felszerelése alapján tudtuk, hogy a vezetékeket 
meg lehet osztani. A legfőbb feltétel az, hogy mindkét olda- 
lon egy időben csak egy rendszer adhat vagy fogadhat ada- 
tot. Mint kiderült ez komoly probléma, mivel az SBE alkat- 
részeket nem úgy tervezték, hogy képesek legyenek inaktí- 
vak lenni mialatt a vonalra csatlakoznak. A kritikus problé- 
ma az volt, hogy a 13 kártya transmittere automatikusan 
bekapcsolt ha a kártya áramot kapott. Így ha két rendszer 
közt élő 13 kör kapcsolatunk van, egy-egy mindkét oldalon, 
és beüzemeljük a tartalék rendszert, a 13 leáll, mivel egy ol- 
dalon két rendszer próbál adatot küldeni. Ez részlegesen 
kezelhető ha a kártya transmitterének shutoff parancsot 
küldünk. Ez azonban azonban a gép elindulása és az OS 
telepítése előtt nem lehetséges, ami néhány perces potenci- 
ális késést jelent. 

Azt is felfedeztük, hogy a koaxiális kábeleken a 13 jelek im- 
pedanciájának meg kell egyeznie. A 13-as kábelek impe- 
danciája /5 ohm. Ha egyszerűen megosztjuk a kapcsolatot, 
a két eredményül kapott kábel impedanciája 37.5 ohm lesz, 
ami az alkatrészeinktől függően vagy elég vagy nem. A 13- 
as kábelek megosztásának helyes módja ha erősített meg- 
osztót alkalmazunk, ahol egy transzformátor mindkét kap- 
csolaton 75 ohm-ra egyenlíti ki az impedanciát. Mi a Micro 
Circuits, Inc passzív erősített osztóit használtuk. 

A T1-esek megosztása sokkal egyszerűbben ment. Itt ele- 
gendő egy RJ-45-ös elosztóval az egyetlen bejövő kábelt két 
kimenő kábellé alakítani. Iovábbá az SBE 411 kártya nem 
kapcsolja be a transmittert a meghajtó betöltése eljött, így 

a kapcsolatot megoszthatjuk a rendszerek közt. 
Valamennyi megosztott kapcsolatot sikerült kialakítanunk. 
Ugyanakkor a 13 kártyáknál tapasztalt indulási és egyéb 
problémák miatt a megosztóink jelenleg nincsenek telepít- 
ve. Amennyiben ezt a lépést is használni szeretnénk, elő- 
ször meg kell győződnünk arról hogy minden sziklaszilár- 
dan működik és csak akkor álljunk neki a megosztásnak. 
Máskülönben a hibakeresések során egyfolytában le kell 
szednünk a megosztást, mivel nem vagyunk biztosak az 
összeállításunk helyességében. 


Saját terjesztés összerakása 

A 256MB-os flash tárolóegység tömör OS telepítést követelt 
meg. A Telemetry-nél valamennyi Linux helyen a Fedora 
Core 1 változatot szabványosítottuk. Így kényelmes megol- 
dás volt az útválasztókon is FC1-et telepíteni. A két célunk: 
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1. A Fedora Core 1-hez hasonló dolgot készíteni ami ráfér 
az apró meghajtóra. 
2. A rendszerbeállítások megváltoztatása, hogy elkerüljük 


a felesleges lemezírásokat. 


Ez azért fontos mert a flash meghajtók élettartama véges, 
így naplófájlokat helyezni rájuk nem túl jó ötlet. 

Mint kiderült, saját Fedora rendszert egészen könnyen ki le- 
het alakítani, különösen a korábbi Red Hat kiadásokhoz ké- 
pest. Az egész dolog kulcsa, a saját rendszer image kialakítása 
egy másik gépen amelyen friss RPM adatásbázis található, 
majd ezt az image fájlt át kell vinni az útválasztóra. Az Linux 
Journal FIP lapjáról letölthető 1 listában (3 ftp.ssc.com/pub/ 
[j/listings/issue126/7661.tgz) bemutatjuk hogyan készíthetjük 
el az alap rendszer image fájlt. A folyamat során először egy 
új RPM adatbázist készítünk az építő rendszeren, felrakjuk 

a minimális RPM készletet felépítve a rendszert majd telepít- 
jük az összes kívánt RPM-et. Én a --aid kapcsolóval utasítot- 
tam az rpm-et, hogy automatikusan oldja fel az összes függő- 
ségi problémát a megadott könyvtárban keresve ahová előző- 
leg az összes Fedora RPM-et feltettem. Így nem kellett kézzel 
kikeresnem az össze függőséget. Miután a rendszert felépí- 
tettük, másoljuk a útválasztóra teszteléshez. A flash meghaj- 
tón elérhető 256MB tárhelyből mindössze 171 MB-ot felhasz- 
nálva működő rendszert tudtunk kialakítani. 


Az útválasztó beállításainak finomhanyolása 

A Linux útválasztó használatának célja, hogy a lemezírás és 
olvasást minimalizáljuk. Ez azért fontos mert a Flash meg- 
hajtó csak korlátozott számú újraírást tesz lehetővé (ez álta- 
lában néhány száz vagy ezer alkalmat jelent). Az ilyen 
műveletek számát úgy csökkentettük, hogy az útválasztót 
laptopként kezeltük. Először is a rendszermagban bekap- 
csoljuk a laptop módot, ahogy azt a Linux Journal 2004 
szeptemberi számában olvashattuk. (A cikk magyarul 

a Linuxvilág 2004 októberi számában olvasható.) Ezzel az 
írásokat elhalaszthatjuk a következő olvasási kérelemig így 
azok nem kerülnek azonnal a lemezre. 

Másodszor, a fájlrendszerünk becsatolási opciói között szin- 
tén állítsuk be az írások elhalasztását. Az ext3 esetében állít- 
suk a jóváhagyássi (commit) időintervallumot 60 másod- 
percre. Majd a fájlrendszert a noatime kapcsolóval csatoljuk 
be így a fájlok olvasása nem fogja kiváltani a az elérési idő- 
pont megváltoztatását. 

Harmadszor, valamennyi naplófájlt mozgassunk át a RAM- 
alapú tmpfs fájlrendszerre. A 2. listában bemutatjuk, ho- 
gyan szerkeszthetjük újra a fájlrendszerünket és mozgat- 
hatjuk a /var összes naplóállományát a /var/impermanent 
alatt található tmpfs fájlrendszerre. Hogy mindez igazán 
hatékony legyen, egy parancsfájlra is szükségünk lesz (3. 
lista) amely a naplófájlokat rendszer leállításakor tar labda- 
ként elmenti, majd rendszerindításkor visszatölti (a 2. és 3. 
lista az Linux Journal FIP helyén szinten elérhető). Ezt 

a parancsfájlt rendszerindításkor a lehető leghamarabb kell 
meghívni a /etc/rc.d/rc.sysinit-ben, leálláskor pedig a lehető 
legkésőbb a /etc/init.d/halt-ban. 


A WAN csatlakozók beállítása 
WAN csatlakozók megtévesztőek! Például a 13 és II meg- 
hajtók a rendszermag HDIC vermének különböző verzióit 
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használják. Ez azt jelenti, hogy a sethdlc program két 
veremhez lefordítva ha a WAN vezeték protokollját be 
szeretnénk állítani. 

Elég sok beállítási lehetőségünk van a 13 vagy I1 körök 
esetében - külső vagy belső időzítés? CRC méret? HDLC 
mód? És így tovább. Szerencsére, az SBE támogatási részle- 
sési tippet adott. 

A négy 11-est egyetlen csatolt körré alakítottuk a tegl segít- 
ségével. Ez ugyan jól működött, de ha az egyik T1-est eltá- 
volítottuk a teljesítmény borzalmas volt még akkor is ha új- 
rakapcsolódott. Munkatársam Bill Rugolsky, megtalálta 

a hiba forrását: a csatlakozás állapotának lekérdezése hiány- 
zik. Az SBE kártya jelenti, hogy a csatlakozás élő-e vagy 
sem, de ez az üzenet a veremig már nem jut el. Így a tegl 
megpróbálta elküldeni a csomagokat a működésképtelen 
csatlakozáson keresztül. Bill az SBE meghajtó foltozásával 
és mások által készített foltok felrakásával végül megoldotta 
a tegl és linkwatch figyelmeztetések problémáját. A meghaj- 
tó foltokat elküldte az SBE-nek, reméljük következő meg- 
hajtó verziójukba már benne lesznek a javítások. 

Az OSPF-et főnökünk, Andy Schorr állította be a WAN csa- 
tolásokon keresztüli útválasztás kezeléséhez. A szükséges 
keretrendszert a nyílt forráskódú Ouagga, a Zebra utódja 
biztosította. Amennyiben az egyik csatlakozás leáll (emlé- 
kezzünk két csatlakozás van, a 13 és a virtuális csatlakozás 
az összekapcsolt 11-eseken keresztül), a Ouagga ezt észre- 
veszi és a csomagokat másik csatolófelületen keresztül küldi 
tovább. A pont-pont (point-to-point) kapcsolatokat hagyo- 
mányosan a másik csatolófelület címének kölcsönzésével ál- 
lítjuk be, amely általában az etho lesz. Mi ezzel szemben 
minden point-to-point csatlakozásnak külön dedikált 
alhálózatot készítettünk. Andy-nek módosítania kellett 

a forráskódot, hogy a Ouagga helyesen működjön ilyen be- 
állítások mellett is. 

Kénytelenek voltunk kidolgozni néhány iptables szabályt 
is, hogy a Ouagga helyesen működjön az összekapcsolt 11- 
eseken. A tegl eszköz csak küldeni tud, így a csomagok so- 
ha nem jelennek meg rajta. Emiatt a Ouagga eldobta a cso- 
magokat, hiszen azok nem jó csatolófelületről érkeznek. 

A problémát néhány iptables szabállyal oldottuk meg. 
Használatukkal az összes T1 csatolófelületen (hdlc0O-tól 
hdlc3-ig) érkező csomag úgy tűnik mintha a tegl/0-ról jönne: 


iptables -t mangle -A PREROUTING -i hdlcWt -j 
TTL --ttl-inc 1 

iptables -t mangle -A PREROUTING -i hdlcMt -j 
55 ROUTE --i1f tegl0 


Összefoglalva a WAN csatolások készítése trükkös dolog, 
elég sok tanulást és csiszolgatást igényel. Ne várjuk, hogy 

a dolgok maguktól működni fognak csak mert összedugtuk 
a kábeleket. 


Akadályok az út során 

Számos problémát kellett megoldanunk mialatt a WAN út- 
választóinkat beállítottuk. Néhány ezek közül a WAN meg- 
hajtókkal kapcsolatos amint azt korábban említettük. Mia- 
latt ezt a cikket írtam, felfedeztük, hogy a 11 teljesítmény 


erősen leromlott és a ping idők erősen változnak - a szoká- 
sos 10ms helyett 1 másodperc is előfordult. A nyomok az 
egyik WAN kártyához vezettek amely nem hozott létre 
megszakításokat; meglazult a PCI foglalatban. Az erősen 
változó csomagidőtartamok azért jöttek létre, mert az azo- 
nos megszakítási vonalat használó többi eszköz (eth0) vi- 
szont küldött megszakításokat. Ezek aztán felébresztették 
az SBE meghajtót és feldolgozták a megszakítást. Az ilyen 
típusú nem egyértelmű hibák rávilágítanak a csatlakozás 
minőségfigyelésének fontosságára. 


A jövő 

Az alaprendszerrel elégedettek vagyunk, de számos fejlesz- 
tést kel még végrehajtanunk. A többszörös I1 összetett csa- 
tolófelülettel kapcsolatos bosszantó problémákra tekintettel 
jelenleg tervezzük, hogy a TI1-eseket egy második 13-asra 
cseréljük. Miután ezt megtettük a teljes vezetékosztást elfe- 
lejthetjük. A vezetékek megosztása egy teljesen új bonyo- 
lultsági szintet visz a rendszerbe és nem vagyunk meggyő- 
ződve róla, hogy megéri. 

lovábbi fejlesztéseket kell végeznünk a két vonal állapot és 
minőség megfigyelése terén. Elég nehéz vezetékszolgálta- 
tóknál panaszt emelni a teljesítményre ha nincsen semmifé- 
le adatunk amivel állításunkat alátámaszthatnánk. 
Kényelmes lenne szabványos kiszolgálókat alkalmazni az út- 
választó gépnek. Folyamatosan figyeljük a nagyobb gyártók 
1U szekrénybe illeszthető gépeit, de valamilyen ok miatt 
egyik sem megfelelő. Az a gond, hogy a BIOS nem engedé- 
lyezi bármilyen IDE eszközről a rendszerindítást. A gyártó is- 
meri ezt a korlátot, de nem javítja ki a BIOS-t. Így aztán előre 


láthatóan magunknak kell elkészítenünk a rendszerünket 

a jövőben. A LAN forgalom kezelésére további belső útvá- 
lasztókat fogunk üzembe helyezni, a kifejlesztett WAN útvá- 
lasztó modellt felhasználva, Flash meghajtóval rendelkező 
1U rendszereken futó minimális Fedora rendszermaggal. 


Osszefoglalás 

Bár a projekt még nem teljes, úgy érzem eleget haladtunk 
hogy értékelni lehessen az eredményeket. A kulcskérdés az, 
vajon újból nekivágnánk-e a dolognak? A válasz egyértel- 
műen igen. A WAN útválasztóink redundáns kapcsolatot 
biztosítanak az iroda és a háttérhely között. A WAN vezeté- 
kek megosztása a redundancia növelésére nem igazán volt 
sikeres, hiszen túlbonyolítja a rendszert. 

A projekt lényegesen hosszabb időt vett igénybe mint erede- 
tileg terveztük, ami általános jellemzője a saját rendszer ki- 
fejlesztésének. A válaszok ott vannak, csak sokáig tart meg- 
találni őket. Egy ügyes, szakértő csoport (mint amilyen ne- 
kem volt) elengedhetetlen az ilyen munkához. Csak ne fe- 
lejtsünk el egy kis többletidőt biztosítani az apró bosszantó 
problémákra, melyek szinte bizonyosan megjelennek majd. 


Linux Journal 2004. október, 126. szám 


Phil Hollenback a lelemetry Investments rend- 
szergazdája New York-ban. Amikor éppen nem 
Linux gépeket frissít vagy görkorcsolyázik, 

Phil wwwv.hollenback.net címen olvasható 
weblapjának fejlesztésével tölti Idejét. 
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FIMI rádió hallgatása a Il lépésről lépésre 


Kezdjük a szoftveres rádiók témáját egy olyan projekttel, amely két FM állomást 


képes egyszerre befogni. 


Linux Journal 2004 júniusi számában megjelent 
AA GNU Radio: A rádiófrekvenciás világ felfedezésé- 

nek eszközei" című cikkemben (Linuxvilág, 2004 
július 68-72. oldal) áttekintést adtam a GNU rádiórendsze- 


2 . 





ali a ar 


szert a rádiófrekvenciás (RF) jelek számítógépes digitalizá- 
lására. Ebben a cikkben azt vizsgálom, miképpen használ- 
hatjuk a GNU Radiot FM műsorok hallgatására. 

Az 1. ábrán a cikkhez használt eszköz felépítése látható. 

Ez a nyers és minden sallangtól mentes megközelítés töké- 
letesen alkalmas a működés magyarázatára. A cikk későbbi 
részében összefoglalom az USRP (Universal Softvare Radio 
Peripherial, univerzális programrádió-periféria) legfonto- 
sabb tudnivalóit is. 

A készülékünk egy közönséges FM dipólantennából, egy 
próbatáblára szerelt kábelmodemes vevőegységből és egy 
20 millió jel másodperc mintavételi sebességű analóg-digitá- 
lis átalakítást végző PCI kártyából áll. A vevőegység beme- 
netére az antenna csatlakozik. A vevőegység IF-kimenete 
egy darab koaxiális kábellel csatlakozik a számítógép hát- 
lapján lévő ADC-bemenetre. A vevőegység próbatáblája 

a PC párhuzamos kapujára van kötve, így lehetőségünk 
van az egység vezérlésére is. 

A használt egységek: a Microtune 4937 DI5 3X7702 kábel- 
modemes vevőegység és egy Measurement Computing PCI- 
DAS 4020/12 ADC kártya. Ez a vevőegység-típus már nehe- 
zen beszerezhető, de mások - mint például a Sharp 
Microelectronics által gyártottak - is jó szolgálatot tesznek 
(lásd a kapcsolódó címeket tartalmazó részt). 

A kábelmodemes vevőegység tölti be az RF előtag szerepét 
és ez felelős azért, hogy a számunkra fontos rádiófrekvenci- 
ás jeltartományt olyan frekvenciasávba konvertálja, amit az 
ADC-egységünk kezelni tud. Esetünkben az egység az 50 
MHZz-300 MHZ-ig tartó frekvenciatartomány egy választha- 
tó 6 MHz-es szeletét alakítja át egy 5.75 MHz frekvenciakö- 
zéppel bíró 6 MHz-es szeletre. Az elvről részletesebben az 
említett júliusi lapszámban megjelent cikkben olvashatunk. 


Vágjunk bele! 

Elsőnek vizsgáljuk meg, mi történik, ha az előtagunkat az 
FM frekvenciasáv közepére, mondjuk 100,1 MHZz-re han- 
goljuk. A 2. ábra mutatja a kapott mintákat az idő függvé- 
nyében. Ez az időtartományban mutatott nézet az, amit egy 
oszcilloszkópon is láthatunk. Ebből sok mindent nem tu- 


26 


Linuxvilág 














2. ábra Az ADC-minták képe az időtartományban 


dunk kiolvasni, az mindene esetre bíztató, hogy a minták a 
170-től 70-ig tartó intervallumba esnek. Ideális esetben a je- 
lek a null értékhez képest szimmetrikusan helyezkednének 
el, de a céljaink szempontjából ez az eltolás nem lényeges. 
A frekvenciatartománybeli vizsgálat további információkat 
szolgáltat. Ebben az esetben egyazon időben 1024 mintát 
veszünk és ennek számítjuk ki a Fourier-transzformáltját, 

a gyors Fourier-transzformáció (FF1) algoritmusának alkal- 
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5. ábra Az FM vevő blokkdiagramja 


mazásával. Ezzel képet kapunk azokról a frekvencia-össze- 
tevőkről, amelyek a bemeneti jelben szerepelnek. A 3. ábrán 
láthatjuk a kapott spektrumot. Az x-tengely a frekvenciát 
jelöli, az y-tengelyen pedig a teljesítmény decibelben kifeje- 
zett (10 " 10g10 teljesítmény) értékei szerepelnek. Az alsó 
határ nulla Hz, a felső pedig 10 MHz, a mintavételi frek- 
venciánk fele. 

A 3. ábrán látható tüskék mindegyike egy-egy rádióállo- 
mást jelent. A programunk elsőre látja mindegyiket! 

Egy állomás hallgatásához módot kell találnunk arra, hogy 
az állomás jeleit elválasszuk az összes többi állomásétól, ala- 
kítsuk át az alapsávra (egyenáram, 0 Hz) és alakítsuk vissza 
a frekvenciamoduláció hatását. Lépésről lépésre végig fo- 
gunk haladni ezeken a folyamatokon, de mindezek előtt 
nézzük, mit is takar az FM rövidítés. 
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T. lista A kvadratúra-demodulátor fejállománya 


$Hifndef INCLUDED GR OUADRATURE DEMOD. CF H 
$fdefine INCLUDED GR OUADRATURE DEMOD. CF H 


ftinclude agr sync block.hz: 


class gr guadrature demod cf; 
typedef boost::shared ptrxgr guadrature demod cf: 
gr. guadrature demod cf sptr; 


gr. guadrature demod cf sptr 
gr make guadrature demod cf (float gain); 


12 
: guadrature demodulator: complex in, float out 
1/ 
class gr guadrature demod cf : public 
gr sync block 
í 
friend gr guadrature demod cf sptr 
gr make guadrature demod cf (float gain); 
gr. guadrature demod cf (float gain); 


float d gain; 


public: 


int sync work ( 
int noutput. items, 
gr. vector. const void star ginput items, 
gr. vector void star goutput items); 


§ 


endif /7" INCLUDED GR OUADRATURE DEMOD CF H 7/ 


Mi az a frekvenciamoduláció ? 

Ahhoz, hogy megértsük egy FM vevő működését, nem árt 
ismernünk az FM jelek keletkezésének módját. A frekven- 
ciamoduláció (FM) során a vivőfrekvencia pillanatnyi érté- 
két a bemeneti jel frekvenciájának a függvényében változ- 
tatjuk. A 4. ábrán láthatjuk az m(t) bemeneti jelet (beszéd 
vagy Zenei jel), és a létrejövő s(t) modulált jelet. Matemati- 
kai precizitással felírva, a pillanatnyi frekvencia mindenkor 
az alábbi összefüggés szerint számolható: 


f(t) - k"rm(t) 4 fc 


Az m(t) jelöli a bemeneti jel frekvenciáját, a k egy állandó 
érték, amely a frekvenciaérzékenységet szabályozza, az fc 
pedig a vivőjel frekvenciája (például 1001 MHz). Emlékez- 
zünk rá, hogy a frekvencia mértékegysége radián/másod- 
perc, így a frekvenciát tekinthetjük forgási gyorsaságnak is. 
Ha integráljuk a frekvenciát, fázist vagyis szögértéket ka- 
punk. Megfordítva pedig a fázis idő szerinti differenciálása 
frekvenciát ad eredményül. Ezek azok a kulcsmotívumok, 
amiket a vevő megépítésekor felhasználunk. 
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6. ábra Gyors Fourier-transzformált a digitális frekvenciaváltó kimenetén 


A biokkdiagram 


Az 5. ábrán látható az FM állomások hallgatására szolgáló 
módszerünk. Ha eltávolítjuk a vivőhullámot, egy olyan 
alapsávú hullámunk marad, amelynek pillanatnyi frekven- 
ciája arányos az eredeti jel m(t) értékével. Vagyis az előt- 
tünk álló feladat nem más, mint eltávolítani a vivőhullámot 
és meghatározni a pillanatnyi frekvenciát. 

Az első rész nem okoz nehézséget, a vivőhullámtól 

a programmal megvalósított digitális frekvenciaváltó 
(DDC) segítségével szabadulunk meg, amelyet 

freg xlating fir filter scf elnevezéssel illettünk. 

Az egység egy numerikus vezérlésű oszcillátorból áll, amely 
azokat a szinusz és koszinusz hullámokat állítja elő, ame- 
lyeket ki szeretnénk oltani, valamint egy keverőből (ez 

a programunk számára egy szorzónak felel meg), és egy ti- 
zedelő véges impulzusválaszú szűrőből. Az scf utótag jelzi, 
hogy ez az egység a bemenetén short (rövid) jeleket fogad, 
a kimenetén komplex jelfolyamot állít elő, a szűrő megadá- 
sához pedig lebegőpontos mintákat használ. 

A digitális frekvenciaváltó azt a trigonometrikus azonossá- 
got használja ki, hogy amikor két f1 és f2 frekvenciájú 
szinuszhullámot összeszorzunk, az eredmény két másik 
szinuszhullámból áll elő, amelyek frekvenciái f1--f2 illetve 
f1-f2. Esetünkben a bemenő jelet szorozzuk a vivőjel frek- 
venciájával. A kimenő jel két összetevőből áll, az egyik a vi- 
vőjel kétszerese, a másik pedig egy nullszintű jel. A kétsze- 
res komponenstől egy aluláteresztő szűrővel szabadulunk 
meg, s így megmarad az alapsávú jelünk. 


A számítási gyorsaság a lényeg! 

A digitális frekvenciaváltó egyenes szoftveres megvalósítása 
rendkívül számításigényes feladat. Ekkor a teljes bemenő 
frekvencián elvégeznénk a szinuszos és koszinuszos jelek 
előállítását és ezek összeszorzását. Egy Pentium 4 processzor- 
ral a szinusz és koszinusz jelek számítása 150 utasításciklust 
igényel. Egy 20 millió je másodperc sebességű bemenettel 
számolva ez 20e6 " 150 — 3e9 ciklust jelentene másodpercen- 
ként csupán a szinusz és koszinusz kiszámítására! Ez nyil- 
vánvalóan járhatatlan út. Jó hír azonban, hogy a DDC szoft- 
veres megvalósításának létezik egy jobb módszere is. Vanu 
Boseet a Virtual Radios" (Virtuális rádiók) című írásában 

- lásd a kapcsolódó címeket — vázolt eljárás szerint a művele- 
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7. ábra A demodulált FM jel gyors Fourier-transzformáltja 


tek sorrendjének átszervezésével és a valóságos együtthatók 
helyett a frekvenciaspecifikus komplex-szűrő együtthatóinak 
használatával elegendő az összes számítást tizedakkora frek- 
vencián elvégezni. Ennek a módszernek az eredménye meg- 


határozó, ezt már valós időben is el tudjuk végezni! 


Kvadratúra-demoduláció 

A következő feladat az alapsávú jel pillanatnyi frekvenciájá- 
nak meghatározása. Erre a guadrature demod cf blokkot 
használjuk. A fázist közelítő módszerrel választjuk le a szom- 
szédos minták közti szögeltérés meghatározásával. Emlékez- 
zünk vissza, hogy a frekvenciaváltó blokk kimeneteként 
komplex számok álltak elő. Egy kis trigonomettriai ismeret fel- 
használásával, két egymást követő minta közti szögeltérést 
meghatározhatunk oly módon, hogy az egyiket megszoroz- 
zuk a másik komplex konjugáltjával és az eredménynek 
vesszük az arkusz tangensét. Az 1. és 2. listán láthatjuk 

a guadrature demod cf blokk megvalósítását. Ha már tud- 
juk, hogy mit akarunk, nem kell sokat kódolnunk. A jelfel- 
dolgozás zömét a sync work ciklusában lévő három sor végzi. 
Mindezeket kipróbálva a 6. ábrán láthatjuk a digitális 
frekvenciaváltó kimenetét, a 7. ábra pedig a kvadratúra- 
demodulátor kimenetét mutatja. A 7. ábrán láthatjuk az FM 
hullámforma összes összetevőjét. A 0-tól körülbelül 16 kHz- 
es frekvenciáig terjedő rész a jobb és bal oldal (LR) együt- 
tes hangtartománya. A 18 kHz-nél látható tüske a sztereo 
pilotjel. A bal és jobb oldal különbségjele (L-R) a pilotjel két- 
szeres frekvenciájának értékére középpontozva jelenik meg 
AM-modulált jelként az FM felső tartományában. Időnként 
további segéd-vivőírekvenciákat is találhatunk az 57 kHz és 
96 kHz közé eső frekvenciatartományban. Hogy ne bonyo- 
lítsuk túl a dolgokat, a kvadrát-demodulátor kimeneti jelét 
16 kHz-es frekvenciánál levágjuk, amivel egy monó jelet ka- 
punk, s ezt a hangkártya kimeneteire kapcsoljuk. 


Égy többcsatornás vevőegység 

A LinuxJournal FIP kiszolgálójáról (lásd a kapcsolódó címe- 
ket) letölthető 3. lista egy általános vevő megvalósításának 
Python-kódját mutatja. Valójában arra is képes, hogy két 
FM állomást fogjon egy időben, egyiket a bal oldali hang- 
szórón keresztül, másikat a jobb oldalin. Nem állítom, hogy 
ennek különösebben nagy hasznát vesszük, mindenesetre 


2 .lista A kvadratúra-demodulátor megvalósítása 


fifdef HAVE CONFIG H 
ftinclude "config.h" 
fendif 


ftinclude cgr guadrature demod cf.h: 
ftinclude cagr 10 signature.h: 


gr. duadrature demod cf: : 
gr guadrature demod cf (float gain) 
: gr sync block ( 
"guadrature demod cf", 
gr. make io signature(1,1,sizeof 
(gr. complex) ) , 
gr. make io signature(1,1,sizeof (float))), 
d gain (gain) 
í 
set history (2); // provide 1 sample look 
// ahead 


gr. guadrature demod cf sptr 
gr. make guadrature demod cf (float gain) 
í 
return gr guadrature demod cf sptr ( 
new gr. guadrature demod cf (gain)); 


int 

gr. gduadrature demod cf::sync work ( 
int noutput items, 
gr. vector const void star ginput items, 
gr. vector void star goutput items) 


:1n -— (gr complex ") input items[01]; 
(float ") output items[0]; 
// ensure that in[-1] i1s valid 


gr. complex 
float "out - 
1n4-; 


for (int 1 — 0; 1 c noutput items; 1---)( 
gr. complex product — in[i] " conj (Cin[1-1]); 
out[1] - d gain " arg (product); 

ő 


return noutput. 1 tems ; 


jól mutatja a programmal megvalósított rádióban rejlő lehe- 
tőségeket. A több csatorna egyidejű vételének ez az ötlete 
felhasználható rádiós TiVo-szerű eszközök alapjaként. 

A kód három függvényre bomlik. A main kezeli a paraméter- 
ellenőrzést, irányítja az RF-előtagot és vezérli a fő jelfeldolgo- 
zó ciklust. Ha csak egyetlen állomást veszünk, az RF előtagot 
arra utasítjuk, hogy az állomást tegye a vevőegység kimeneti 
frekvenciájának közepére (az IF-re). Ha két állomást fogunk, 
azoknak egymástól 5,5 MHz-es távolságon belül kell lenniük. 
Ennek a megszorításnak a kábelmodemes vevőegységben lé- 
vő SAW-szűrő az oka. Ez egy 5,/5 MHZ-re beállított sávát- 
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eresztő szűrő, melynek értéke a 6 Mhz-es érték - az észak- 
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amerikai IV-csatornák sávszélességének -— közelében van. 
Ebben az esetben a különbséget megfelezzük, és az előtagot 
pontosan a két állomás közé hangoljuk. A build graph az ál- 
talános jelfeldolgozó blokkokat tartalmazza és kapcsolja egy- 
máshoz. Mind az egy, mind pedig a több csatorna vételi eljá- 
rásánál egyetlen nagy sebességű analóg-digitális átalakítót 
használtunk a bemeneten és egy hangkártyát a kimenet szá- 
mára. Minden egy időben hallgatni kívánt csatorna számára 
külön digitális frekvenciaváltó, kvadratúra-demodulátor és 
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aluláteresztő szűrő került megvalósításra. 


Többféleképpen is megvalósítható! 

Az egyszerre fogható adók száma a számítógépünk sebes- 
ségének függvénye. Még eme ötletes megvalósításunkra 

is igaz, hogy a processzorciklusok nagy része 

a freg xlating fir filter blokkokkal terhelt. Az álta- 
lunk most ismertetett módszer a nyers ADC-módszer nevet 
kaphatná. A számítási igény csökkentésének egyik módsze- 
re a digitális frekvenciaváltás végrehajtásának hardveres 
megvalósítása lenne. Több gyártó, így a Iexas Instruments, 
Intersil és Analog Devices cégek is kínálnak olyan céláram- 
köröket (ASIC), amelyek képesek e feladat betöltésére. 

A Universal Software Radio Peripherial (USRP) által köve- 
tett módszer a digitális frekvenciaváltó Verilog hardverleíró 
nyelven való lekódolása, majd a keletkezett bittolyam USB- 
kapun keresztül az FPGA-ba való áttöltése. Ezzel egy olyan 
kombinált megoldást kapunk, amely megőrzi a maximális 


s a 


rugalmasságot, ugyanakkor lehetővé teszi a számításigé- 
nyesebb részek végrehajtásának hardverre történő átterhe- 
lését. Az URSP vonatkozásában további információk a GNU 


Radio Wikin érhetők el. 


Összegzés 

A cikkben egy egyszerű, de teljes funkcionalitású többsávos 
FM vevőt vizsgáltunk meg, miközben sikerült egy több ezer 
dolláros hardvert két ötdolláros tranzisztort tartalmazó rádió- 
val egyenértékűvé tennünk, és képet kaptunk a feldolgozó 
folyamatokról is. Akiket mélyebben is érdekel az FM rádió- 
zás, a GNU Radio kódtárában egy lényegesen jobb minőségű 
FM vevőre (hifi fm.py) és egyéb finomságokra bukkanhat. 

A GNU Radio terén mostanra rengeteg értékes munka szüle- 
tett, amelyek némelyike a mozgó ideiglenes hálózatokat veszi 
célba, mások az amatőr rádiózás hagyományait követik vagy 
a szoftveres GPS megvalósításán fáradoznak, egy csoport pe- 
dig lázasan dolgozik a következő generációs föld-űr amatőr 
műholdas kommunikációs rendszer megteremtésén. Habár 

a GNU Radio eszközkészlet nagymértékben független a ki- és 
bemeneti eszközöktől, ezeknek a törekvéseknek a nagy része 
az USRP-t használja, vagy tervezi használni a rádiófrekvenci- 
ás egységek és a számítógép közti csatolófelületként. 


Linux Journal 2004. október, 126. szám 


Eric Blossom a GNU Radio Project alapítója. 
Évekig dolgozott a biztonságos telefonszol- 
gáltatások területén mielőtt programalapú rádli- 
ózással kezdett foglalkozni. Ha éppen nem 
programalapú rádiót bütyköl, akkor valószínű- 
leg jógázással vagy Ju-jitsuval tölti idejét. 

Az ebocomsec.com címen érhető el. 
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Alkalmazások teljesítményének növelése a folya- 
matok szinkronizálásával HPC rendszereken 


Hahó, fürtesomópont, most ne dolgozz azon a karbantartási munkán — mind- 
annyian arra várunk, hogy befejezd az MPIl munka rád eső részét! Ismerjünk 
meg egy hatékony fürtkezeléshez használható ütemezési rendszabály. 


zt várhatnánk, hogy ha megduplázzuk az alkal- 
AA mazásra jutó számítási erőt az alkalmazás teljesít- 

ménye is duplájára nő vagy a futásidő felére csök- 
ken. Sajnos azonban a HPC felhasználók jól tudják ez bi- 
zony távol áll az igazságtól, ugyanis az aktuális hatékony 
teljesítmény akár a rendszer elméleti csúcsteljesítményének 
597o-ára is visszaeshet. A HPC kutatók és alkalmazás fejlesz- 
tők rengeteg időt fordítottak és fordítanak ma is arra, hogy 
megtalálják az ilyen teljesítményvesztés forrását és feltor- 
násszák az alkalmazás teljesítményét. Amikor elkezdtünk 
a Cray XD1 rendszeren dolgozni, magunk is csatlakoztunk 
a problémával foglalkozó kutatók sorába. Cikkünk arról 
szól, hogyan tanultunk az előttünk járóktól, és hogyan épí- 
tettünk erre a tudásra kifejlesztve egy Linux-ütemező alapú 
megoldást, amely lényegesen megemelheti a Linux HPC 
rendszerek alkalmazásainak teljesítményét. 
A legtöbb kutató a HPC alkalmazások szerkezetére koncent- 
rált. Különféle kutatócsoportok próbálták növelni a gyorstá- 
razás hatékonyságát, keresték a processzorközi kommuni- 
káció csökkentésének lehetőségeit és vizsgáltak hasonló ele- 
meket, de egyik stratégia sem hozott néhány százaléknál 
komolyabb javulást. Egy másik kutatási terület azonban 
sokkal ígéretesebbnek tűnik. Ha megértjük milyen kapcso- 
lat van a HPC alkalmazás és a rendszer háttér folyamatai 
között, megpróbálhatjuk megváltoztatni ezt a kölcsönhatást 
megnövelve a teljesítményt. 





Hova tűnik a teljesítmény? 

Ez irányú kutatásaikat ismertető ötletadó írásukban Petrini, 
Kerbyson és Paking a Los Alamos National Laboratory kuta- 
tói (lásd a hálózati forrásokat) azt állítják, az alkalmazások 
teljesítményét egy általuk , zajnak" nevezett tényező okoz- 
za — nevezetesen a nagy több ágon futó MPI munkafolya- 
matok és a háttérfolyamatok közötti kapcsolat. Megfigyel- 
ték, hogy a karbantartási feladatok, azaz a zaj miatt egyes 
processzorok nem tudták elérni az MPI korlátot (szinkroni- 
zálási pontok az alkalmazásban) emiatt az összes folyamat- 
nak rájuk kellett várakozni, míg a processzor végre befejez- 
te a karbantartást. Ez az összes többi processzoron elpaza- 
rolt ciklusokhoz vezetett. 
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Az 1. ábra felső része ezt a kapcsolatot és az általa okozott 
teljesítményvesztést mutatja be. A bemutatott folyamatok 
egy párhuzamos munka részei, valamennyi külön pro- 
cesszoron fut, melyek időnként az MPI korlátok segítsé- 
gével szinkronizálnak. A számítás első felében az 1. folya- 
mat késlekedett, mivel a csomópont ütemezője leállította 
a folyamat végrehajtását, hogy a minden Linux vagy 
UNIX csomóponton megtalálható szokásos háttérfo- 
lyamatok egyikét futtassa. A 2. és 3. csomópont szintén 
késlekedik. EF minta megismétlődése jelentősen csökkent- 
heti alkalmazás teljesítményét. A hatás nagyságrendje 

a korlátok felbukkanásának sűrűségétől és a processzo- 
rok számától függ. 

Petrini és kollégái ezt a teljesítményvesztést egy az össze- 
nyomható fluidumok Euler típusú hidrodinamikai viselke- 
dését leíró kód, a SAGE futtatásakor figyelték meg ASCI 0 
nevű HEC rendszerükön. Az ASCI 0 egy 2,048 darab HP 
ES45 csomópontból álló fürt, ahol minden csomópont maga 
is négy utas SMP rendszer. Petrini és társai megfigyelték, 
hogy amennyiben több mint 256 csomópontot bevontak 

a számításba, jobb teljesítményt értek el a SAGE-el, ha 

az SMP rendszereken a négyből csak három processzort 
futtattak. Feltételezték, hogy az eltérést a zaj okozza, 

majd elképzelésüket bizonyították a zajforrások egy 
részének kiküszöbölésével, amely érzékelhető teljesít- 
ménynövekedést okozott. 

A kutatások rámutatnak, hogy a folyamat szinkronizálás 
hiánya és várakozási idő a bűnös, amely az egyébként fino- 
man hangolt és erősen párhuzamosított HPC alkalmazások 
potenciális teljesítményének akár 50970-át (vagy még többet) 
is elrabolhatja. Sajnos az ilyen tolvajlás kiküszöbölése nem 
éppen kézenfekvő. A bűnös azonosítására Petrini és társai 
által alkalmazott módszer - a rendszer szabadságfokainak 
korlátozása a karbantartási munkák végzése terén - a leg- 
több HPC alkalmazásban nem igazán járható út. A legtöbb 
HPC tulajdonos számára nem igazán kívánatos eljárás, 
hogy a rendszer processzorainak egynegyedét karbantartási 
munkák kössék le. Ráadásul a sok háttérfolyamatot nem 
lehet eltávolítani, így ezzel a megközelítéssel elérhető meg- 
takarítás erősen korlátozott. 
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1. ábra Példa folyamatok szinkronizált és aszinkron végrehajtására 


A hiányzó teljesítmény visszaszerzése 

Ha rászánjuk magunkat egy új nagy teljesítményű számító- 
gép összeállítására, valahogy ki kell találnunk, hogyan aka- 
dályozhatjuk meg ezt a teljesítménytolvajlást. Kidolgoztunk 
egy új eljárást, amely a Linux ütemező segítségével próbálja 
meg szinkronizálni az MPI és a karbantartási munkafolya- 
matok ütemezését. Korábbi munkáink és kutatásaink azt 
sugallják, hogy az új szinkronizált ütemezési megközelítés 
akár 5090 vagy még komolyabb teljesítnénynövekedést is 
okozhat egyes 32 vagy több processzoron futó, finom han- 
golt, párhuzamosított alkalmazásnál. 


Szinkronizált ütemezési rendszabályok bevezetése 
Elképzelésünk alapja egy új Linux ütemezési rendszabály 
bevezetése volt. A kívánt előnyök elérése érdekében a rend- 
szabálynak a Linux HPC rendszer összes gépén szinkroni- 
zálnia kell az ütemezőket biztosítva, hogy az MPI folyama- 
tok az összes folyamattal párhuzamosan futnak ugyanak- 
kor a Linux karbantartási folyamatok is végrehajtódnak. 
Így az ütemezőnek valamilyen módon meg kell tudnia 
valósítani az 1. ábrán bemutatott globális szinkronizálást. 
A globális szinkron elérése érdekében a kommunikációért 
felelős processzorhoz terveztünk egy kiegészítést amely 

az összes feldolgozó csomóponton szinkronizálja az órát. 
Az új Linux ütemező rendszabály 128 hellyel rendelkező 
ütemezési keretet szab meg amelyből 120 az alkalmazás 
végrehajtására, nyolc pedig a karbantartási munkákra 
van fenntartva. A különböző processzorok ütemezői 

a globálisan szinkronizált órához igazíthatják saját üteme- 
ző munkájukat, amely a rendszer csomópontjai közt leg- 
feljebb mikroszekundum alatti eltéréseket jelenthet. 
Bármely időpillanatban az összes processzor vagy a HPC 
alkalmazást futtat vagy a karbantartási folyamatokat 
végez (az 1. ábra alsó fele). 

A folyamatszinkronizálás ilyen megközelítése nagy számú 
processzorra is jól skálázható, hiszen az ütemezési döntést 
minden csomópont maga végzi el. Az eljárás a korlátokra 
várakozó CPU ciklusok megszüntetésével jelentősen meg- 
növelheti a megnyirbált teljesítményt. 

A szinkronizált ütemezőt új rendszabályként készítettük 
el a Linux kernel ütemezőjéhez már korábban elkészült 
három létező rendszabály kiterjesztéseként. A Linux üte- 
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mező akkor lép működésbe ha a végrehajtott folyamat 
elakad, önként átadja a CPU-t, illetve ha a processzor 
megszakítást érzékel vagy a 10 milliszekundumos idősze- 
let lejár. Az ütemező a következő futtatandó folyamatot 
az ütemezési rendszabály alapján választja ki a folyamat 
jellege és fontossága alapján. Az új ütemezési rendsza- 
bállyal felvértezett Linux két valós idejű és a két hagyo- 
mányos időosztásos folyamatokat támogató ütemezési 
rendszabály közül választhat. Ezek fontossági sorrendben 
a következők: 


1. FIFO (első be, első ki): A FIFO jelölésű folyamat ad- 
dig fut, míg el nem ereszti a CPU-t. Ezt a prioritást 
csak rövid ideig használjuk a valós idejű rendszer- 
folyamatoknál. A FIFO folyamatok mindig elsőként 
futnak le. 


0 Kiskapu Kft. Minden Jog fenntartva 


2. Körbejáró (Round robin): Az ilyen rendszabályt hasz- 
náló folyamatok sorjában megkapják a 10 millisze- 
kundumos időszeletüket. Valós idejű feldolgozáshoz 
használatos. 


9 


Szinkronizált: A szinkronizált rendszabályt azért adtuk 
a rendszerhez, hogy a kötegelt többprocesszoros mun- 
kánál lehetővé tegyük a szinkronizált feldolgozást. 

A terheléskezelő rendszer minden folyamatot ezzel 

a rendszabállyal jelöl meg indításkor. A folyamatok 

és gyermekeik kihasználhatják a szinkronizált üteme- 


zés előnyeit. 


4. Előjogokon alapuló (Priority): Az előjogokon alapuló 
ütemezés nem más mint a Linux felhasználók számára 
jól ismert időmegosztási módszer. Azok a folyamatok 
melyek ezt a rendszabályt alkalmazzák előjogokkal 
rendelkeznek és előjogaiknak megfelelően kapnak idő- 
szeleteket. Lényegében minden felhasználói és rendszer 
folyamat ez alatt a rendszabály alatt fut. Az ütemező 
a legmagasabb fontossági szinten álló osztályból választ- 
ja ki a következő futtatandó feladatot. A FIFO és körbe- 
járó rendszerfolyamatok következnek legelőször. 

A szinkronizált végrehajtásra jelölt feladatok pedig 
előbb következnek mint a hagyományos előjogos üte- 
mezőben megadottak. 


Az új szinkronizált ütemező rendszabály létrehoz egy 
ütemező keretet, amely eldönti mikor lehet végrehajtani 
a kötegelt és az egyéb felhasználói illetve rendszer folya- 
matokat. A keretben előre megadott számú hely van, 
amelyek sorrendben egymás után következnek. Egy 
időhely10 milliszekundumot jelent, Linux alatt ugyanis 
ennyi egy ,rendszerpillanat" (tick), ami alatt a időhelyhez 
rendelt folyamat futhat. Jelenlegi megvalósításunkban 128 
időhely van, amelyből 120 a kötegelt munkák végrehajtá- 
sára szolgál és 8-at tartunk fenn a rendszerfolyamatok ré- 
szére. Ez utóbbi időhelyek alatt a szinkronizált ütemező 
jelzi, hogy nincs futtatandó kötegelt folyamat és így 

a karbantartási munkákhoz használható hagyományos 
ütemezési rendszabály lép érvénybe. Amennyiben nincs 
kötegelt munkafolyamat, a Cray ütemező megkülönböz- 
tethetetlen a megszokott Linux ütemezőtől. 
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2. ábra Időhelyek (128) nyolc fenntartott időhellyel 





Az ütemezési keretben található helyek száma állítható, 
azonban kötelező kettő hatványnak lennie. A többi folya- 
mattal szemben a kötegelt folyamatok részére fenntartott 
mennyiség szintén beállítható. A 2. ábra egy tipikus üteme- 
zési keretet mutat be, ahol a kötegelt munkák részére fenn- 
tartott rész vörös, a karbantartási munkák időhelyei pedig 
szürke színűek. 

Az ütemező keret a csomóponton elindított első kötegelt 
folyamattal egy időben jön létre. Ilyenkor az összes kötegelt 
időhely ehhez a folyamathoz tartozik. A további kötegelt 
folyamatok hozzáadása során az időhelyek egyenletesen el- 
oszlanak a folyamatok közt. Ha n számú kötegelt folyama- 
tot hozunk létre, az első kötegelt folyamat a helyek 120/n-ed 
részét kapja, a második a következő 120/n időszeletet és így 
tovább. Így a szinkronizált ütemező olyan kötegelt munká- 
kat is ki tud szolgálni a processzorokon amelyek egynél 
több folyamatot igényelnek. 

A kötegelt folyamat a megkapott idő végéig futhat, feltéve, 
hogy nincs akadályozva és nincs CPU-t átadó rendszerhí- 
vás. Amennyiben a kötegelt folyamat átadja a CPU-t, példá- 
ul mert blokkoló rendszerhívást végez, egy másik kötegelt 
folyamat kerül végrehajtásra. Amennyiben nincs futtatható 
kötegelt munka, a vezérlés a hagyományos ütemezőhöz ke- 
rül ahol a karbantartási feladatok lefuthatnak. lermészete- 
sen a kötegelt folyamat visszakapja a CPU-t amint a meg- 
szakítás kezelése után kioldódik. 


Ütemezési keretek kiosztása a processzorok közt 

Ez idáig kizárólag az egy csomóponton végzett kötegelt 
munka és rendszerfolyamat ütemezéssel foglalkoztunk. 

A teljesítmény elorzásának megakadályozásához, az üteme- 
zőnek valamennyi processzort be kell vonnia. Itt egy rend- 
kívül fontos tervezési feladatba botlunk, amely végső soron 
lehetővé teszi a szinkronizált ütemezést, nevezetesen a glo- 
bális időszinkronizálás kérdésébe. Megoldásunkban a glo- 
bális időszinkronizálást a HPC rendszerbe tervezett kom- 
munikációs processzorok végzik. Ezek a processzorok 

a kommunikációs feldolgozás terhét veszik le a többi alkal- 
mazás processzorról. A kommunikációs processzorok az 
egységes időzítés érdekében egyúttal időszinkronizációs 
feladatokat is ellátnak. A pontos időszinkronizációt azért 
érhetjük el, mert a kommunikációs processzorok vezérel- 
ni tudják a csomagidőzítést és ugrálást, és így bármely 

két processzor közötti időeltérés kevesebb lesz mint 1 mik- 
roszekundum. Azzal, hogy a szinkronizációs feladatokat 
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A folyamatok szinkronizálásával elért gyorsulás 
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3. ábra Folyamatszinkronizálással elérhető elméleti gyorsulás 1.596 
Démon CPU foglaltság esetén 


a kommunikációs processzorokkal végeztetjük, további 
előnyökhöz jutunk, hiszen az alkalmazás terhelést kiszol- 
gáló processzorokról leveszünk bizonyos mennyiségű 
munkát, így több idő marad az alkalmazás kiszolgálására 
valamint a megszakítások száma is csökken az alkalmazás 
processzorokon. 

Az idő szinkronizációs protokoll kiegészítő helyeket tartal- 
maz az időhely kiosztáshoz. A protokoll mester szolga el- 
gondolás szerint működik, ahol az egyik csomópont szolgál 
idő és időhely információ forrásként az összes többi csomó- 
pont pedig a mester csomópont órájához igazodik. A mes- 
tertől kapott időszinkronizálási csomagok azonosítják 

a végrehajtandó időhelyet és az időhely indítása óta eltelt 
időt, így a teljes HPC rendszerben precízen megadhatóak 
az ütemező keretek. 


Teljesítmény kérdések 

A szinkronizált ütemező a párhuzamos alkalmazások 
folyamatainak szinkronizált végrehajtását teszi lehetővé. 
Hogy mekkora teljesítménycsökkenést lehet elkerülni, 
vagy mekkora potenciális teljesítmény érhető el, az az al- 
kalmazás által használt korlátok és gyűjtőműveletek szá- 
mától, a rendszer karbantartó folyamatok által elhasznált 
időmennyiségtől és az alkalmazásban felhasznált pro- 
cesszorok számától függ. 

Kutatásaink azt mutatják, hogy a módszerrel jelentős gyor- 
sulást lehet elérni. A 3. és 4. ábra a szinkronizált ütemező ál- 
tal elérhető elméleti gyorsulást mutatja a hagyományos elő- 
jogos ütemezővel szemben. A 3. ábrán feltételeztük, hogy 

a háttérfolyamatok a processzor 1.5970-át foglalják le, a 4. áb- 
ra szerint pedig a háttérfolyamatok a CPU 6.2590-át igénylik 
-— ezek egyébként a legtöbb valódi fürtön tapasztalható érté- 
kek. A bemutatott görbék másodpercenkénti 100, 200 és 
300-as korlátszámnak felelnek meg. 

Ahogy a processzorok száma növekszik, a szinkronizált 
ütemező nyújtotta előnyök aszimptotikusan közeledik 

a maximum felé. Ez azt a tényt tükrözi, hogy a hagyomá- 
nyos ütemezővel sem csökken akármeddig a teljesít- 
mény. Bizonyos processzorszám elérése után annak 

a valószínűsége, hogy legalább egy processzor karban- 
tartási munkát végez, közelít a 10099-hoz. Iovábbi pro- 
cesszorok hozzáadása lényegesen már nem növeli a kor- 
látoknál észlelhető alkalmazás csúszást. 
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4. ábra Folyamatszinkronizálással elérhető elméleti gyorsulás 6.596 
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Osszefoglalás 

A HPC alkalmazás és a rendszer háttérfolyamatai közötti 
kölcsönhatásra fokuszálva, a HPC kutatók rátaláltak a pár- 
huzamos alkalmazások teljesítménycsökkenésének egyik fő 
okára. lovábbi kutatások e tolvajlás megakadályozásának 
lehetőségére is fényt derítettek, de ez egyelőre még egyet- 
len valódi működő megoldás sem létezik. A Linux ütemező- 
jét használó globális folyamat szinkronizálás megszünteti 

a zaj várakozási időt és jelentős teljesítménynövekedéssel 
kecsegtet. A HPC rendszer egyéb szabályai és az alkalmazá- 
son túllépve úgy hisszük, rábukkantunk egy valódi, komo- 
lyan használható megoldásra. Globális óraszinkronizálást 
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alkalmazó Linux folyamatszinkronizálással és az egyes cso- 
mópontokon futtatott Linux rendszerekkel a Cray megoldá- 
sa az Összes processzoron képes biztosítani az alkalmazás 
folyamatainak párhuzamos futását miközben a karbantartá- 
si folyamatok kötött időben, szintén párhuzamosan futnak 
le. Folyamatszinkronizáló megoldásunk megelőzheti a telje- 
sítményvesztést és akár 50970-al is megnövelheti a finom fel- 
bontású erősen párhuzamosított alkalmazások teljesítmé- 
nyét a 32 vagy több processzort alkalmazó rendszereken. 


Linux Journal 2004. november, 127. szám 


Dr. Paul Terry a Cray által 2004 áprilisában felvásárolt, ko- 
rábban OctigaBay Systems néven ismeretes, Cray Canada 
vezető műszaki szakembere. Az új számítási szerkezetek 
technológiai stratégája, aki a cég műszaki elképzeléseinek 
és vezető helyzetének megalapozásáért felelős. 


Amar Shan a Cray termelésirányítási igazgatója, a Cray él- 
vonalbeli műszaki újításalért és kreatív üzleti megoldásalért 
felelős. Több mint 20 éves tapasztalattal rendelkezik a szá- 
mítási és telekommunikációs ipar termékmenedzsmentje, 
fejlesztése és architektúra szabályai terén. 


Pentti Huttunen a Cray teljesítménymérési szakértője aki 

a párhuzamos számítási eljárások kidolgozásáért és az alkal- 
mazások optimalizálásért felelős. Munkájának fő célja az, 
hogy ezek az alkalmazások a Cray különféle gépein a lehető 
leghatékonyabban fussanak. 
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Unionfs: eggyé váló fájlrendszerek 


Az Unionfs több könyvtárat is képes egyetlen nézetben egyesíteni. 
A továbbiakban az Unionfs alkalmazásait, valamint működésének 


néhány érdekes kérdését tárgyaljuk. 


z egymáshoz kapcsolódó, ám különböző fájlokat 
AA a könnyebb kezelés miatt sokszor érdemes elkülö- 

nítve tárolni. A felhasználók viszont inkább együtt 
szeretnék látni őket. Ilyenkor a rendszergazda egy egyesítés- 
sel elérheti, hogy fizikailag elkülönítve maradjanak, logikai- 
lag azonban mégis egyetlen nézetben legyenek elérhetők 
a fájlok. Az egybevont könyvtárak halmazát uniónak nevez- 
zük, minden fizikai könyvtár ennek egy ága. Amint az 1. áb- 
rán is látható, a Unionfs egyszerre több fájlrendszer felett 
vagy adott fájlrendszer több könyvtára felett alkot újabb ré- 
teget. Ezt a rétegezéses megoldást vermelésnek nevezzük, 
az internetes források között bővebben is lehet olvasni róla. 
A Unionfs a rendszermag felé egy fájlrendszer felületet mu- 
tat, míg az alatta üzemelő fájlrendszerek őt a rendszermag 
VES-ének látják. Mivel a Unionfs fájlrendszerként látszik 
a rendszermag számára, bármely felhasználói alkalmazás, 
illetve a rendszermag felől az NFS-kiszolgáló is igénybe ve- 
heti szolgáltatásait. A Unionfs elfogja az alacsonyabb szintű 
fájlrendszerekkel végzett műveleteket, és ezek módosításá- 
val képes az egységes nézet biztosítására. A korábbi ver- 
melhető fájlrendszerekkel ellentétben a Unionfs valóban le- 
gyezőként terült szét az alsóbb rétegek felett, és nagy számú 
alsóbb szintű ágat képes közvetlenül elérni. 


Az Unionfs szemantikája és használata 

Unionfs alatt minden ágnak van egy elsőbbségi szintje, 
precedenciája. A magasabb elsőbbségi szintű ágak elnyom- 
ják az alacsonyabb szintűeket. A Unionfs könyvtárakkal 
dolgozik. Ha egy könyvtár két ágban is megtalálható, akkor 
a Unionfs-ben megjelenő könyvtár tartalma és jellemzői 

a két könyvtár kombinációjából tevődnek össze. A Unionfs 
magától eltávolítja a kettős könyvtárbejegyzéseket, így a fel- 
használókat nem zavarják meg a kettős fájl- és könyvtárne- 
vek. Ha egy fájl két ágban is jelen van, akkor a Unionfs alatt 
látható fájl tartalma és jellemzői a magasabb elsőbbségi 
szintű ágban találhatóval egyeznek meg, az alacsonyabb 
szintű ágban lévő fájlt a rendszer elnyomja. 

Példaként tegyük fel, hogy két könyvtárat egyesítünk, ezek 
a /Gyümölcsök és a /Zöldségek: 


$ ls /Gyümölcsök 
Alma Paradicsom 
$ 1s zöldségek 
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1. ábra Egy unió számos alsóbb szintű ágból áll, amelyek tetszőleges 
típusú fájlrendszerrel üzemelhetnek 


Répa Paradicsom 

$ cat /Gyümölcsök/Paradicsom 
Növénytanilag gyümölcs vagyok. 

$ cat /zöldségek/Paradicsom 

A kertészek zöldségként kezelnek. 


A Unionfs használatba vételéhez először le kell fordítanunk 
a Unionfs modult, majd be kell töltenünk. Következő lépés- 
ként, mint minden más fájlrendszert, a Unionfs-t is be kell 
fűzni. Az egyéb fájlrendszerekkel ellentétben a Unionfs 
nem egy eszköz, hanem a befűzésekor megadott könyvtá- 
rak fölé helyezkedik el. Unió létrehozásához a következő- 
képpen kell befűznünk a Unionfs-t: 


ft mount -t unionfs -o dirs-/Gyümölcsök: zöldségek 
55 none /mnt/egészséges 


A fenti példában a befűzéskor átadott dirs értékkel adjuk 
meg az uniót alkotó könyvtárakat. Mivel a Unionfs eszközt, 
meghajtót nem használ, a none (semmi) helyőrzőt használ- 
juk. Utolsóként a /mnmt/egészséges értéket adjuk meg, 
amely az egyesített nézet helye. Most a /mnt/egészséges 
könyvtár három fájlt tartalmaz: Alma, Répa és Paradicsom. 
Mivel a /Gyümölcsök könyvtárat a /zöldségek előtt adtuk 
meg, a /mnt/egészséges/Paradi csom fájl tartalma 

a , Növénytanilag gyümölcs vagyok". Ha a dirs- átadott 
érték elemeit megfordítjuk, akkor a /mnt/egészséges/ 
Paradicsom tartalma az , A kertészek zöldségként ke- 
zelnek" lesz. (Egyébként ez utóbbi felel meg az USA Legfel- 
sőbb Bírósága a témában 1893-ban hozott döntésének.) 

A folyamat rekurzív. Ha a Gyümölcsök könyvtárban lenne 
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egy Zöld nevű alkönyvtár, amely tartalmazná a zöldcitrom 
fájlt, a zöldségek könyvtárban pedig volna egy szintén 
zöld nevű alkönyvtár, benne a Saláta fájllal, az eredmény 

a következő lenne: 


$ ls /mnt/egészséges 

Alma Répa Zöld/ Paradicsom 
$ ls /mnt/egészségeszzöld 
zöldcitrom Saláta 


A Unionfs számos különböző célra használható. Alkalmas 
például arra, hogy több kiszolgálóról egyesítsük a kezdő- 
könyvtárakat, vagy több ISO képfájlt összevonva egységes 
képet alkossunk egy terjesztésről. Hasonlóan, az Unionfs 
másolás írás közben szemantikával alkalmas CD-lemezek 
tartalmának foltozására, amivel forráskód kezelésére vagy 
pillanatfelvételek készítésére is megfelel. 


Egyesített kezdőkönyvtárak 

Egy-egy ügyfélgép gyakran több különböző NFS-kiszolgá- 
lóról fűzi be a kezdőkönyvtárat. Szerencsétlen megoldás, 
hiszen ilyenkor mindegyik kiszolgálóhoz külön befűzési 
pont tartozik, ami kényelmetlen a felhasználó számára. 

A legjobb az lenne, ha mindegyik kezdőkönyvtárat ugyan- 
arról a helyről, például a /home könyvtárból lehetne elérni. 
Az automatikus befűzők egy része szimbolikus hivatkozáso- 
kat használ, az egyesítés látszatát keltve. Unionfs alatt ilyen 
hivatkozásokra nincs szükség. Két különálló könyvtár telje- 
sen egyszerűen egyesíthető egyetlen nézetben. legyük fel, 
hogy két fájlrendszerünk van, ezek /alcid és /pingvin 
névvel vannak befűzve. A /home könyvtárban a következő 
módon egyesíthetjük őket: 


f mount -t unionfs -o dirs-/alcid,/pingvin 
sss none /home 


Így a /alcid és a /pingvin kezdőkönyvtára egyaránt elér- 
hető a /home könyvtárból. 

a felhasználói fájlokat nem kell egyik könyvtárból átmoz- 
gatni a másikba. Ebben is eltér a korábbi egyesítő megoldá- 
soktól, például a 4.4-es BSD-ben található Union Mounts 
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támogatnak. 


Terjesztések 150 képfájljainak egyesítése 

A legtöbb Linux-terjesztés ISO képfájlok és különálló cso- 
magok formájában egyaránt elérhető. Az ISO képfájlok ké- 
nyelmes megoldást nyújtanak, hiszen közvetlenül fel lehet 
írni őket CD-lemezre, letölteni és külön tárolni csak néhány 
fájlt kell. Ha viszont hálózaton keresztül kell telepítenünk 
egy gépet, sokszor jó volna, ha az egyes csomagokat egyet- 
len könyvtárban látnánk. A hurokeszköz segítségével az 
ISO képfájlokat ugyan be tudjuk fűzni különböző könyvtá- 
rakba, ám a hálózati telepítéshez ez az elrendezés nem felel 
meg, hiszen az összes fájlnak egyetlen faszerkezetben kell 
lennie. Éppen ezért sok helyen az ISO képfájlokból és az 
egyes csomagfájlokból egyaránt fenntartanak egy másola- 
tot, ami viszont a tárhely és a sávszélesség pazarlását, vala- 
mint a felügyeleti feladatok szaporodását eredményezi. 
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A Unionfs segítségével egy könnyed huszárvágással oldhat- 
juk meg a problémát, ha képzetesen egyesítjük az ISO kép- 
fájlok csomagokat tartalmazó könyvtárait. 

Az alábbi példában két könyvtárat fűzünk be, ezek a /mnt/ 

lemez1 és a /mnt/lemez2. A befűzési parancs a következő: 


$ mount -t unionfs -o dirs-/mnt/ lemez1 , /mnt/ l emez2 
55 none /mnt/egyesített-terjesztés 


Ezután a /mnt/egyesített-terjesztés könyvtárat NFS-en 
vagy FIP-n keresztül használhatjuk a hálózati telepítésekhez. 


Másolás írás közben típusú uniók 

Az iménti példában az unió minden ága csak olvasható 
volt, ennél fogva magát az uniót is csak olvasni lehetett. 

A Unionfs képes csak olvasható és írható-olvasható ágak 
egyesítésére is. Ilyenkor az unió maga írható-olvasható lesz, 
és az Unionfs másolás írás közben megoldást használva an- 
nak a látszatát kelti, hogy a csak olvasható ágak fájljainak és 
könyvtárainak módosítására is van lehetőségünk. Ezzel 

a módszerrel például CD-lemez tartalmát tudjuk frissíteni, 
foltozni. Ha a CD-ROM-meghajtót a /mnt/cdrom alá fűztük 
be, valamint van egy /tmp/cdfolt könyvtárunk is, akkor 

a következő parancsot adjuk ki: 
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f mount -t unionfs -o dirs-/tmp/cdfolt, /mnt/cdrom 
sss none /mnt/foltozott-cdrom 


A /mnt/foltozott-cdrom könyvtáron keresztül nézve úgy 
tűnik, mintha írni lehetne a CD-lemezt, de természetesen 
az írások a /tmp/cdfolt könyvtárba történnek. Egy csak 
olvasható ág írása egy fölémásolásnak nevezett műveletet 
eredményez. Ha egy csak olvasható fájlt írásra nyitunk 
meg, akkor a fájlrendszer átmásolja egy magasabb elsőbbsé- 
gi szintű ágba. Szükség esetén a Unionfs magától létrehozza 
a szülőkönyvtárak szerkezetét is. 

A CD-lemezes példában az alacsonyabb szintű fájlrend- 
szer kötelező érvénnyel betartja a csak olvashatóságot, 

az Unionfs pedig figyelembe veszi ezt. Lehetnek olyan 
esetek is, amikor az alacsonyabb szintű fájlrendszer 
ugyan írási-olvasási hozzáférést enged, ám az Unionfs 
számára meg akarjuk tiltani az ág módosítását. Lehet pél- 
dául egy águnk, amely eredeti rendszermag forráskódo- 
kat tartalmaz, és dönthetünk úgy, hogy emellett egy 
másik ágat használunk a helyi módosítások tárolására. 

A Unionfs-en keresztül az eredeti ágat csak olvashatóvá 
is tehetjük, hasonlóan az előző példa CD-lemezéhez. 
Ehhez csak az -ro kapcsolót kell hozzáadjunk a dirs be- 
fűzési átadott értékhez. legyük fel, hogy a /home/cpw/ 
linux könyvtár üres, és a /usr/src/linux tartalmazza 

a Linux rendszermag forráskódjának könyvtárait. Az 
alábbi paranccsal a Unionfs-t forráskód-változatkövető 
rendszerré alakíthatjuk: 


$ mount -t unionfs -o 
ss dirs-/home/cpw/ linux: /usr/src/linux-ro 


ss none /home/cpw/linux-src 


A parancs kiadása után úgy fogjuk érzékelni, mintha egy 
teljes Linux forráskód lenne a /home/cpw/linux-src 
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könyvtárban, ám bármilyen módosítást is hajtunk végre raj- 
ta, a megváltozott vagy új fájlok valójában a /home/cpw/ 
linux könyvtárba kerülnek. 

Egy egyszerű módosítással elfedő befűzést is választha- 
tunk, ekkor a /home/cpw/1inux könyvtárat egységes 
nézetben látjuk: 


ff mount -t unionfs -o 
ss dirs-/home/cpw/linux:/usr/src/linux-ro 
ss none /home/cpw/linux 


Megvalósítás 

Unionfs alatt a legtöbb fájlrendszerbeli művelet a magasabb 
elsőbbségi szintű ágak felől az alacsonyabb elsőbbségi szintű- 
ek felé halad. A LDOKUP (keresés) például a szülőt tartalma- 
zó legmagasabb elsőbbségi szintű ággal kezd, innen halad az 
alacsonyabb szintűek felé. A keresések alatt az Unionfs a ké- 
sőbbi műveletek céljaira gyorstárazza az adatokat. 

A CREATE (létrehozás) a szülőkönyvtárat tartalmazó leg- 
magasabb elsőbbségi szintű könyvtárban kísérli meg a fájl 
létrehozását. A CREATE művelet a gyorstárazott keresési 
adatokra támaszkodik, így biztosítva, hogy közvetlenül 

a megfelelő ággal dolgozzon, így lényegében a magasabb 
ágak felől mozog az alacsonyabbak felé. 

A Unionfs számos módszert alkalmaz a csak olvasható ágak 
látszólagos módosíthatóságának fenntartására, miközben 

a közönséges, UNIX-ra jellemző szemantikát is megőrzi. 
Ha egy fájl létrehozása közben hiba történik, akkor hibake- 
zelést kell végezni. A hibakezelés a legalacsonyabb elsőbb- 
ségi szintű ág felől a magasabbak felé halad. A szülőt tar- 
talmazó legmagasabb elsőbbségi szintű ággal kezdve az 
Unionfs mindegyik magasabb szintű ágban megkísérli a fájl 
létrehozását. Végül, ha a művelet a legmagasabb szintű ág- 
ban a teljes unióra nézve sikertelen, az Unionfs hibát jelez 

a felhasználó felé. 

A CREATE művelettel ellentétben az UNLINK (leválasz- 
tás) mindig a legalacsonyabb elsőbbségi szintű ágtól halad 
a legmagasabb felé. Mivel az utolsó leválasztandó objek- 
tum a legmagasabb fontossági szintű objektum, a felhasz- 
náló szemszögéből semmi sem változik, amíg az Unionfs 
UNLINK művelete teljesen be nem fejeződik. A legbonyo- 
lultabbak a részleges hibák. Ha egy köztes fájlt nem sike- 
rül eltávolítani, és az Unionfs egyszerűen törli a legmaga- 
sabb fontossági szintű fájlt, akkor az alacsonyabb fontos- 
sági szintű fájl válik láthatóvá a felhasználó számára. A hi- 
bahelyzetek kezelésére az Unionfs egy különleges, magas 
elsőbbségi szintű fájlt használ, ennek neve whiteout (kb. 
kihagyás). Ha az Unionfs kihagyás fájllal találkozik, akkor 
úgy viselkedik, mintha a kérdéses fájl egyik alacsonyabb 
elsőbbségi szintű ágban sem létezne. Az Unionfs belső 
folyamatai például az F nevű fájlhoz a kihagyás fájlt egy 
nulla bájtos .wh.F nevű fájl formájában hozzák létre. 
Visszatérve a leválasztás művelethez: ha egy köztes levá- 
lasztás végrehajtása sikertelen, akkor a legmagasabb el- 
sőbbségi szintű fájlt az Unionfs nem törli, hanem a megfe- 
lelő kihagyás névre kereszteli át. 

A műveletek gondos sorrendezése két dolgot eredményez. 
Az első, hogy a unixos szemantika még hibák felmerülése- 
kor és csak olvasható ágak kezelésekor is sértetlen marad. 
A felhasználó által látott állapot mindaddig érintetlen ma- 


36 Linuxvilág 


rad, amíg a művelet el nem ér a legmagasabb elsőbbségi 
szintű ágig. A művelet sikerességét vagy sikertelenségét az 
ebben az ágban kapott eredmény határozza meg. A kiha- 
gyás fájlok használatával adott fájlt még akkor is lehet tö- 
rölni, ha az csak olvasható ágban található. A második fon- 
tos hatás, hogy ha nem történik hiba, akkor a fájlok és 
könyvtárak azokban az ágakban maradnak, ahol eredetileg 
is voltak. Ez fontos szempont, hiszen a Unionfs egyik fő cél- 
ja a fájlok különböző helyeken tartása. 


A fájlok törlésének szemantikája 

Alapesetben az Unionfs az összes ágból törli a megadott 
fájl vagy könyvtár példányait, ezt amódot DELETE ALL 
(teljes törlés) módnak nevezzük. A teljes törlés mellett 

az Unionfs további két törlési módot is támogat, ezek 

a DELETE WHITEOUT (kihagyás törlése) és 

a DELETE FIRST (első törlése). A kihagyás törlése kívül- 
ről szemlélve az alapmódhoz hasonlóan működik, ám az 
unió összes vonatkozó fájljának törlése helyett egy kiha- 
gyás fájlt hoz létre. Ennek az az előnye, hogy az alacso- 
nyabb elsőbbségi szintű fájlok az alsóbb szintű fájlrendsze- 
reken keresztül elérhetők maradnak. Az első törlése mód 
szakít a hagyományos unixos szemantikával, és csak az 
unió legmagasabb elsőbbségi szintű bejegyzését távolítja el, 
aminek eredményeként az alacsonyabb elsőbbségi szintű 
bejegyzések láthatókká válnak. Mindezeket a módokat 

a RENAME (átnevezés) művelet is segítségül hívja, ez 
ugyanis egy létrehozásból és egy azt követő törlésből áll. 
Az első törlése művelet használatához a felhasználónak is- 
mernie kell az unió összetevőit. A mód elsősorban akkor 
használható jól, ha a Unionfs-t a korábbi rendszermag 
forráskódfás példához hasonlóan forráskód változatainak 
követésére használjuk. Ha a /home/cpw/linux könyvtárban 
megváltoztatunk egy fájlt, akkor a rendszer felmásolja 

a magasabb elsőbbségi szintű ágba. Ha a fájlt a normál tel- 
jes törléssel távolítjuk el, az Unionfs egy kihagyás fájlt hoz 
létre a legmagasabb elsőbbségi szintű ágban - a csak olvas- 
ható alacsonyabb elsőbbségi szintű ágat ugyanis nem tudja 
módosítani. Az eredeti, az alacsonyabb elsőbbségi szintű 
ágban lévő forrásfájl ezzel elérhetetlenné válik, így a forrás- 
ból kell bemásolni az unióba, ez viszont aligha fogadható el 
egy változatkövető rendszertől. Pontosan ezek azok a hely- 
zetek, amikor az első törlése mód jól jön. A törlési módot 
befűzéskor adhatjuk meg, például: 


ff mount -t unionfs -o 
ss dirs-/home/cpw/flinux:/usr/src/linux-ro, 
ss delete-first none /home/cpw/linux 


Most, ahogy korábban is, ha módosítunk egy a /home/ 
cpw/1inux könyvtárban lévő fájlt, a /usr/src/ linux 
könyvtár tartalma érintetlen marad. Ha meggondoljuk ma- 
gunkat, és nem akarjuk megtartani a változásokat, akkor 
egyszerűen töröljük a fájlt, ekkor újra láthatóvá válik az 
eredeti változat. 


Unionís pillanatfelvételek 

Az untonctl segédprogrammal az Unionfs ágait üzem köz- 
ben is meg lehet változtatni. Az unió bármelyik pontjára 
új ágat csatolhatunk, tetszőleges ágat kivehetünk, vala- 


mint írható-olvasható ágakat csak olvashatóvá változtat- 
hatunk, illetve fordítva. Rugalmasságának köszönhetően 
az Unionfs a fájlrendszer pillanatfelvételének elkészítésé- 
re is használható. A következő példában a /usr könyvtár- 
ról készítünk pillanatfelvételt, miközben telepítünk egy 
új csomagot: 


$ mount -t unionfs -o dirs-/usr none /usr 


Ezen a ponton a Unionfs egyetlen írható-olvasható ággal 
rendelkezik, és ez a /usr. Minden művelet továbbkerül az 
alsóbb szintű fájlrendszerhez, minden úgy zajlik, mintha 

a Unionfs jelen se lenne. 

A pillanatfelvétel elkészítése két lépésből áll. Az első a pilla- 
natfelvétel fájlok helyének megadása, amely egy ág - ez le- 
gyen például a /pillfelv/0 — hozzáadásával történik: 


f unionct] /usr -add /pillfelv/o 


Ekkor a Unionfs a /usr könyvtárba szánt új fájlokat 

a /pilIfelv/0 könyvtárban hozza létre, miközben a /usr 
könyvtár alkönyvtáraiba mentett fájlok továbbra is a /usr 
könyvtár alá kerülnek. A látszólagos ellentmondás abból 

a szabályból fakad, hogy a fájlokat a legmagasabb elsőbbsé- 
gi szintű olyan ágban kell létrehozni, amelyben a szülő léte- 
zik. Az unió gyökérkönyvtárának, vagyis a /usr könyvtár- 
nak a fájljai esetében a szülő mindkét ágban létezik. Mivel 
a /pil Ifelv/0 a magasabb elsőbbségi szintű ág, az új fájlok 
és könyvtárak fizikailag a /pi I I felv/0 könyvtárban jönnek 
létre. A /pilIfelv/0 viszont üres, ezért, ha létrehoznánk 
egy fájlt a /usr/local könyvtárban, akkor a legmagasabb 
elsőbbségi szintű szülő a /usr ágban lenne. 

Az áttelepítés teljessé tételéhez az eredeti /usr ágat csak ol- 
vashatóvá kell tenni. Ismét az unionct1-t használjuk az 
ágak módosítására: 


$ unionct] /usr —-mode /usr ro 


Most, köszönhetően annak, hogy az Unionfs a /usr könyv- 
tárat csak olvashatónak látja, minden írási művelet tényle- 
gesen a /pi I Ifelv/0 könyvtárra irányítódik. Löbb pillanat- 
felvételt is készíthetünk, ha létrehozunk egy újabb ágat, 
például /pillfelv/1 névvel, és a /pilIfelv/0 ágat csak ol- 
vashatóként jelöljük meg. 

Az első pillanatfelvételt a /usr könyvtáron keresztül látjuk. 
Mindegyik pillanatfelvétel egy alapkönyvtárból és további, 
az eltéréseket növekményi formában tartalmazó könyvtá- 
rakból áll. Ha megadott pillanatfelvételre vagyunk kíváncsi- 
ak, akkor csupán egyesítenünk kell az első pillanatfelvételt 
és a növekményes változásokat. Ha például a /usr és 

a /pil Ifelv/0 könyvtárak tartalmából összeálló pillanat- 
felvételt akarjuk elérni, az Unionfs-t a következőképpen 
kell betűznünk: 


f mount -t unionfs -o ro, dirs-/pillfelv/0:/usr 
ss none /mnt/pillfelvétel 


Ebben az esetben az Unionfs maga is csak olvashatóként 


kerül befűzésre, az alsóbb szintű könyvtárakat tehát 
nem lehet módosítani. 
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A pillanatfelvételen végrehajtott módosítások helyességé- 
nek ellenőrzése után a következő lépés gyakran a pillanat- 
felvétel beolvasztása az alapba. A Unionfs letölthető cso- 
magjában egy snapmerge nevű parancsfájl is szerepel, ez 

— a pillanatfelvétel könyvtárában lévő fájlokat rekurzívan az 
alapkönyvtárba másolva - a növekményes Unionfs pillanat- 
felvételeket képes összeolvasztani az alapkönyvtárral. 

A másolási eljárás befejezése után az új és a módosított fáj- 
lok hiánytalanul rendelkezésünkre állnak. A végső lépés 

a fájltörlések kezelése, amely a kihagyás fájlok listájának 
létrehozásával és a megfelelő fájlok törlésével történik. 
Maguk a kihagyás fájlok szintén törlésre kerülnek, így 

nem terhelik feleslegesen a fát. 


Osszefoglalás 

A Unionfs rekurzívan egyesít akár nagyobb számú könyv- 
tárat vagy ágat is egyetlen képzetes nézetben. Hatékony, 
legyezőszerű szerkezete révén a Unionfs számos alkalma- 
zási területen állja meg helyét. A Unionfs például ISO 
képfájlok egyesítésére, összevont /home könyvtár biztosí- 
tására és rengeteg további célra használható. Az Unionfs 
másolás írás közben szemantikájának köszönhetően vál- 
tozatkövetésre, pillanatfelvételek készítésére és CD-le- 
mezek foltozására is alkalmas. Az Unionfs teljesítményét 
2.4-es Linux alatt vizsgáltuk. Fordítási feladatoknál egy- 
négy ág kezelésekor az Unionfs miatti többletterhelés 
mindössze egy-két százalék volt. A nagy mennyiségű 

be- és kiviteli műveletet végző folyamatoknál a többlet- 
terhelés egy ág esetén 10, négy ág esetén pedig 12 száza- 
lék körüli volt. 
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Postfix kiszolgáló bővitése Clam Antivirussal 


Linuxos levélkiszolgálónkat nagyteljesítményű védelmi vonallal felszerelve 
megvédhetjük a bajtól a sérülékeny rendszereket. 


Linux Journal 2004-es Szerkesztői Díját a biztonsá- 
AA gi eszközök között a ClamAV, egy teljes mérték- 
ben szabad és nyílt forrású víruskereső kapta, 
amely ugyan jellemzően Linuxon fut, ám számos különbö- 
ző géptípus vírusait képes felismerni. (Lásd: Linuxvilág, 
2004. szeptemberi szám) Mint Rewven Lerner a díjakról szó- 
ló cikkben megjegyezte, a , ClamAV miatt az üzleti víruske- 
reső programok tényleg futhatnak a pénzük után". 
Ez alkalommal szeretném megmutatni, hogy Postfix alapú 
elektronikus levél átjárónkon hogyan használhatjuk ki 
a ClamAV tudását. Eközben szó esik majd az Amavisd-new- 
ról, erről a sokoldalú, elektronikus levelek feldolgozására 
használható démonról, amely létfontosságú összekötőként 
szolgál a levélkiszolgálók, mint a Postfix és a Sendmail, 
valamint a leveleket ellenőrző eszközök, mint a ClamAV 
és a SpamAssassin között. 


A rendszer felépítése 

A továbbiakban ismertetendő összeállítás természetesen 
nem az egyetlen lehetséges vagy jó lehetőség a ClanAV 
használatára. Ez ugyanakkor a legelterjedtebb megoldás 

- mondjuk úgy, jellegzetesnek nevezhető. legyük fel, van 
egy SMIP átjárónk, az internet felől ez fogadja a saját cé- 
günk, szervezetünk számára címzett elektronikus leveleket, 
a célunk pedig az, hogy az SMIP átjáró előzetesen ellen- 
őrizze, a levelek nem tartalmaznak-e vírust. (1. ábra) Az átjá- 
ró feladata lehet az, hogy a leveleket a helyi postaládákban 
helyezze el, de belső levélkiszolgálónak való továbbításra 

is beállíthatjuk. A következőkben foglaltak függetlenek 

a tényleges levéltovábbítási módszertől. 

Ha nagy forgalmú rendszert üzemeltetünk, akkor lehetsé- 
ges, hogy az SMIP átjáró helyett a víruskeresést inkább egy 
különálló géppel érdemes elvégeztetnünk - az itt ismerte- 
tett eszközök ekkor is működni fognak. Az egyszerűség 
kedvéért azonban, illetve igazodva a szokásokhoz, most te- 
gyük fel, hogy a víruskereső magán az SMIP átjárón fut. 
Levéltovábbító ügynökként (Mail Transfer Agent, MTA) 
Postfixet használunk, ez ugyanis egy népszerű és biz- 
tonságosan futtatható program, továbbá a ClamAV-vel 

is gond nélkül képes együttműködni. Csakhogy 

a Postfix nem tud közvetlenül kapcsolatba lépni 

a ClamAV-vel, vagy legalábbis ez a kapcsolat nem megbíz- 
ható. A ClamAV sem jeleskedik az elektronikus levelek 
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elemzésében, inkább adatfolyamokkal tud dolgozni. Ezért 
van szükségünk a kisegítő démonra, az Amavisd-new-ra. 
Az Amavisd-new szintén ingyenes és nyílt forrású eszköz, lé- 
tének egyetlen célja az MTA-k, mint a Postfix és a Sendmail, 
valamint a víruskereső és a szemétszűrő programok, mint 

a ClamAV és a SpamAssassin közötti tranzakciók közvetítése. 
Az Amavisd-new egyebek mellett kiválóan teljesít az elektro- 
nikus levelek MIME mellékleteinek hagyományos, a keresők 
által is érhető adatfájlokká alakításában. 

Az Amavisd-new démonja, az amavisd számos protokollon 
keresztül képes kommunikálni, ide értendő az SMIP és az 
LMITP elektronikus levéltovábbító protokoll mellett a UINIX 
foglalatok rendszere is. Ebben az esetben az amavisd-t úgy 
állítjuk be, hogy a leveleket SMIP-n keresztül, a 10024-es 
számú ICP kapun át fogadja, annak helyi UNIX foglalatán 
keresztül lépjen kapcsolatba a ClamAV-vel, majd a levelet 
és a víruskeresés eredményét a 10025-ös ICP kapun adja 
tovább a Postfixnek. A leveleknek az SMIP átjárón keresz- 
tüli mozgását a 2. ábra szemlélteti. 


A program beszerzése és telepítése 

A ClamAV és az Amavisd-new egyaránt Perlben íródott, és 
számos Perl-modultól függ. Mindenkinek javaslom tehát, 
hogy a két eszköz valamelyik újabb változatának saját ter- 
jesztéséhez készült bináris csomagját használja. Még egy- 
szerűbb, ha az apt-get, a Yum vagy az up2date szolgáltatása- 
ira hagyatkozunk, így nem kell foglalkoznunk a függőségek 
kézi telepítések során felmerülő gondjával. 

A ClamAV webhelye, amellett, hogy itt lelhető fel a legújabb 
ClamAV forráskód is, tartalmaz egy oldalt, amelyen 

a ClamAV különféle Linux-terjesztésekhez és egyéb operáci- 
ós rendszerekhez készült bináris csomagjainak elérhetősé- 
gét gyűjtötték össze. A Red Hat vagy Fedora terjesztést 
használók Dag Wieers oldalán (lásd az internetes forráso- 
kat) találnak Yum ágakat és up2date forrásokat, ClamAV-t és 
Amavisd-new-t egyaránt. Az Amavisd-new weboldalon to- 
vábbi Amavisd-new csomagok forrásaira mutató hivatkozá- 
sokat is találunk, illetve a legújabb Amavisd-new forráskó- 
dot is innen tölthetjük le. A ClamAV a sarge kiadása óta 

a Debian alapcsomagja, az Amavisd-new pedig például 

a SuSE rendszerekben a 9.1-es kiadás óta szerepel. 

Ha bármelyik összetevőt forráskódból vagy önálló csomag- 
ból telepítjük, akkor a Yum, up2date vagy apt-get alapú 
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1. ábra Példa levelezőrendszer 


megoldással ellentétben nekünk kell ügyelnünk arra, hogy 
az Amavisd-new-hoz tartozó telepítési leírás Prereguisites 
(előfeltételek) című részében foglaltakat teljesítsük. Sajnos 
a ClamAV telepítésének feltételeit eléggé hiányosan foglal- 
ták össze. Ha kétségeink támadtak, semmibe sem kerül sa- 
ját ClamAV RPM-ünk nevével kiadni az 


rpm -test -iv clamav csomagnév.rpm 


parancsot, így láthatjuk, hogy mi hiányzik még a gépünkről. 
Ha van egy kis szerencsénk, akkor terjesztésünkhöz elérhe- 
tők a ClamAV és az Amavisd-new használatához szükséges 
Perl-modulok csomagjai. Amit mégsem találunk, azt a CPAN- 
ról vagy az egyéb, a saját terjesztésünkhöz készített csoma- 
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gokkal foglalkozó weboldalak valamelyikéről tölthetjük le. 
A ClamAV beállítása 


A ClamAV és az Amavisd-new telepítése után nekiláthatunk 
a beállítások megadásának. A ClamAV-vel kezdünk, ez az 
egyszerűbb. A ClamAV beállító fájlja a /etc/clamav.conf. 
Nyissuk meg a kedvenc szövegszerkesztőnkkel. Az 1. ábrán 
azok a beállítások láthatók, amelyeket a legtöbbeknek azon- 
nal meg kell változtatniuk. 

Az első sor ártatlannak tűnik, de mindenképpen tegyük 
megjegyzésbe. Ha ezt elmulasztjuk, a clamd nem fog futni. 
A két LogFi le. . . beállítás alapesetben megjegyzésként sze- 
repel. Ha engedélyezni akarjuk a naplózást, vegyük ki őket 
megjegyzésből. A naplófájlt mi választjuk ki, maximális mé- 
rete LogFi leMaxSi ze, ennek elérésekor a fájl felülírásra kerül. 
A DatabaseDirectory kulcsfontosságú beállítás. A ClanAV 
itt tárolja a vírusaláírások adatbázisait, mondhatnánk, az 
agyát. Az általam telepített ClanAV RPM-ben található 
clamd démon úgy volt lefordítva, hogy a /usr/share/clamav 
könyvtárat használta erre a célra, miközben a hozzá mellé- 
kelt példa clamav.conf fájlban a /var/lib/clamav érték szere- 
pelt, igaz, megjegyzésbe téve. Úgy döntöttem, kiveszem 
megjegyzésből a sort, és /usr/share/clamav értékre módosí- 
tom, kerülendő a félreértéseket. 

A LocalSocket beállítás azt határozza meg, hogy a clamd 
melyik foglalaton keresztül tartja a kapcsolatot a külvilággal, 
jelen esetben az Amavisd-new-val. Ha használjuk ezt a beállí- 
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2. ábra A Postfix, az Amavisd-new 
és a ClamAV közötti adatáramlás 


tást, márpedig én ezt javaslom, akkor ügyel- 
jünk arra, hogy a TCPSocket és a TCPAddr 
beállítás megjegyzésben maradjon. Saját 
Genco csomagomnál a LocalSocket elérési út 
alapértéke /tmp/clamd volt, amivel az a baj, 
hogy a /tmp bárki által írható-olvasható. 
Helyette javaslom a /usr/share/clamav/ 
clamd. sock elérési út választását, a /usr/ 
sharejclamav engedélyeit pedig állítsuk 
rwxrwx értékre, vagyis vonjuk meg az egyéb 
Az 1. kódrészlet utolsó beállítása a User, ez 
annak a felhasználónak a neve, amelynek 
fiókjával a clamd-nek indulása után futnia 
kell. A clamd-t a rootnak kell elindítania, 

de ha ezt a beállítást kivesszük megjegyzés- 
ből, majd értéket adunk neki, akkor a clamd 
indulás után lefokozza önmagát. 

A legtöbbünk számára elég ennyit ismerni 

a /etc/clamav.conf fájlból. A clamd indítása előtt ellenőrizzük, 
hogy van-e rendszerünkben fiókja a clamav-nek, és a /etc/ 
clamav.conf fájlban szereplő elérési utakra vonatkozó enge- 
délyeket megfelelően beállítottuk-e. A fiók csoportjaként 
szintén érdemes a clamav-t választani. Amint a következő 
részben látni fogjuk, így könnyebben meg tudunk osztani 
bizonyos erőforrásokat a clamd és az amavisd között. 

A /etc/ passwd bejegyzése a clamav fiókhoz a következő: 


clamav:x:52:52:ClamAv Daemon:/:/bin/false 

A /etc/group fájl clamav csoportfiókja pedig a kö- 
vetkező: 

clamav:x:52: 


Ha a clamd beállításán is túlestünk, elindításához csupán 

a clamd parancsot kell kiadnunk. Ha a ClamAV-t bináris cso- 
magból telepítettük, /etc/init.d névvel valószínűleg bekerült 
rendszerükbe a clamd indító parancsfájlja is. Ha így van, ak- 
kor ne feledkezzünk el az engedélyezéséről, így a clamd már 
a rendszer betöltésekor elindul. Ha a fájl hiányzik, akkor 
magunknak kell gondoskodnunk a létrehozásáról. 


Az Amavisd-new beállítása 

Ahogy a clamd, úgy az amavisd beállításait is egyetlen fájl 
tárolja, ez a /etclamavisd.conf. Ezzel azonban egy kicsit több 
munkánk lesz. A 2. kódrészlet saját /etc/amavisd.conf fájlom 
legfontosabb elemeit tartalmazza. 

A 2. kódrészlet első két beállítása a $daemon user és 

a $daemon group, ezek az amavisd futtatásához használt 
felhasználói és csoportfiókot adják meg. Értékük rendre le- 
gyen amauvis és clamav. Mint korábban említettem, szerin- 
tem érdemes közös csoportba rendelni az amavisd és 

a clamd fájljait, így tehát van értelme az amavisd-t is ezzel 
a csoporttal futtatni. Az amavishoz tartozó /etc/passwd be- 
jegyzés így néz ki: 


amavis:x:53:52:Amavisd-new 
Daemon: /var/amavis : /bin/false 


A $mydomain szervezetünk tartománynevét adja meg. 
A $MYHOME, amelyet az amavis fiókjának kezdőkönyvtárára 
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kell állítani, az Amavisd-new fájljainak gyökérkönyvtárát 
határozza meg, ez általában a /var/amavis. Erre a könyvtár- 
ra csak a root kapjon írási jogot, és a tulajdonjogot is neki 
adjuk. A $OUARANTINEDIR annak a könyvtárnak az elérési 
útja, amelybe az amavisd-vel a karanténba helyezett elekt- 
ronikus leveleket el szeretnénk helyeztetni. A könyvtár tu- 
lajdonosa az amavis felhasználói fiókja legyen, és kizárólag 
ez kapjon írási jogot hozzá. 

A $db home, melyet lehetséges, hogy ki kell vennünk meg- 
jegyzésből, azt határozza meg, hogy az amavisd hol tárolja 
adatbázisait, például a gyorstárazott keresési eredményeket. 
A $helpers home az a könyvtár, amelybe az amavisd saját 
SpamAssassin beállításait írja, és néhány további apróságot 
helyez el. Lehetséges, hogy alapesetben a $helpers home 
megjegyzésként szerepel. A $db. home és a $helpers home 
könyvtárat az amavis felhasználói fiókja birtokolja, és kizá- 
rólag általa legyen írható. 

A $pid fileésa $l]ock file, melyek szintén megjegyzés- 
ként kerülhetnek a kezünk alá, az amavisd folyamatazono- 
sító és zárolási fájljának helyét adják meg. 

A $1og level szabja meg, hogy az amavisd naplóüzenetei 
mennyire legyenek részletesek. Itt 0 - 5 közötti értéket ad- 
hatunk meg, ahol az 5 jelenti a legrészletesebb naplózást. 
Az alapérték 0, személyes tapasztalatom szerint a 2-es szint 
elegendő adatot szolgáltat, de a naplófájl sem hízik kezel- 
hetetlen méretűre. Alapesetben az amavisd naplóüzeneteit 
mai 1 erőforrásként a syslog-nak küldi el, vagyis az amavisd 
és a Postfix naplóüzenetei ugyanarra a helyre kerülnek. 

A következő négy beállítás az amavisd által vírus vagy 
levélszemét felismerésekor küldött levelekre vonatkozik. 

A $virus. admin az az elektronikus levélcím, amelyre a ví- 
rusokról szóló értesítőket kapni fogjuk. Érvényes címnek 
kell lennie, ha az itt szereplő érték még nem szerepelne 
benne, akkor gondoskodjunk a helyi aliases fájl frissítésé- 
ről. A gyakorlatban itt jellemzően a rendszergazda, vagyis 
a saját címünk szerepel. 

Arra is van lehetőség, hogy az amavisd az egyes levelek ere- 
deti címzettjeinek vagy küldőjének küldjön értesítést, ám ez- 
zel csak bosszúságot fogunk okozni másoknak, hiszen a levél- 
szemetek és a vírusos levelek feladójának címe szinte mindig 
hamis. Jobb tehát, ha lemondunk erről a lehetőségről. 

A $mailfrom notify admin és 

a $mailfrom notify spamadmin rendre azt a feladócímet 
adja meg, amellyel az amavisd a vírusokról és a levélszeme- 
tekről szóló értesítő leveleket feladja. 

Ezen a ponton végre elérkeztünk az amavisd.conf lényegé- 
hez: a ClamAV-hez tartozó víruskereső beállításokhoz. Ná- 
lam az alapértelmezett /etc/amavisd.conf fájl a teljes részt 
megjegyzésbe téve tartalmazta, tehát azzal kezdtem, hogy 
töröltem a 7 karaktereket a sorok elejéről. Szükség esetén 
tehát ne feledkezzünk meg erről a lépésről. 

Mindenképpen ellenőrizzük a clamd foglalatának ebben 
értelmezett /var/run/clamav/clamd helyett 

a /usr/share/clamav/clamd.sock elérési út szerepel, ugyanaz, 
mint amit a /etc/clamav.conf fájlban adtunk meg. 

Ha megfelelően átírtuk a /etc/amavisd.conf fájlt, és beállítot- 
tuk az amavisd könyvtáraira vonatkozó engedélyeket, ak- 
kor az amavisd parancsot -— kapcsolók nélkül - kiadva indít- 
hatjuk el a programot. Ahogy a clamd, úgy lehetséges, hogy 
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1. kódrészlet Nem alapértelmezett beállítások 
a /etc/clamav.conf fájban 


f Példa 

LogFile /var/log/clamd. log 
LogFileMaxSize 5M 

DatabaseDirectory /usr/share/clamav 
LocalSocket /usr/share/clamav/clamd.sock 
User clamav 


az amavisd számára is létre kell hoznunk egy indító 
parancsfájlt. Javaslom, hogy elsőként a clamd-t indítsuk. 
Így elérhetjük, hogy mire az amavisd elindul, addigra 

a clamd foglalata már jelen legyen. 

A clamd-hez hasonlóan az amavisd-t is a rootnak kell 
indítania. A program ezt követően az amavisd.conf 
fájlban megadott felhasználó és csoport jogosultságaival 
fut tovább. 


A Postfix beállításai 

ClamAV és Amavisd-new démonunk megkapta a kellő beál- 
lításokat, és el is indult. Még ne dőljünk hátra, némi tenni- 
valónk még akad, ugyanis be kell állítanunk a Postfixet 

a tartalomszűrésre, továbbá frissítenünk kell a ClamnAV 
vírusadatbázisát. 

Egy fontos megjegyzés: a továbbiakban feltételezem, hogy 
a Postfix már be van üzemelve, és képes ellátni normál fo- 
gadó/továbbító feladatait. 

Először nyissuk meg kedvenc szövegszerkesztőnkkel 

a /etc/postfix/master.cf fájlt, majd — amennyiben még nem 
szerepelnek ott - fűzzük a 3. kódrészletben látható sorokat 
a fájl végére. 

Az smtp-amauvis rész a Postfix kimenő, az amavisd-vel 
SMIP-n keresztül létesített kapcsolataira vonatkozik. 

Ide a következő sor tartozik, ezt kell hozzáaádnunk 

a /etc/postfix/main.cf fájlhoz, illetve átírnunk, ha már sze- 
repel benne: 


content filter -—- smtp-amavis:[127.0.0.1]:10024 


Ezzel a sorral arra utasítjuk a Postfixet, hogy a master cf fájl- 
ban megadott smtp-amavis felületen keresztül minden be- 
jövő levelet küldjön ki a 127.0.0.1 címre, vagyis a helyi 
rendszernek, mégpedig a 10024-es TCP kapun, az amavisd 
alapértelmezett SMIP figyelő kapuján át. Az amavisd figye- 
lő kapuját a /etcl/amavisd.conf fájl $inet socket port beál- 
lításának átírásával változtathatjuk meg. 

A 3. kódrészlet második szakasza azt a bejövő felületet 
adja meg, amelyen keresztül a Postfixnek fogadnia kell 

az amavisd által visszaadott üzeneteket. A Postfix tehát 

a helyi hurokfelület, a 127.0.0.1-es IP-cím 10025-ös TCP 
kapuján hallgatózik, ez az a kapu, amelyre alapesetben 

az amavisd az értesítéseket és a továbbított üzeneteket 
küldi. Az amavisd értesítési és továbbítási címét és 

kapuját rendre a /etc/amavisd.conf fájlban szereplő 

$notify method és a $forward method beállítások át- 
írásával változtathatjuk meg. A master.cf és a main.cf 
módosítása után a Postfixet újra kell indítani. 


2. kódrészlet A /etc/amavisd.conf fontosabb beállításai 


$daemon user - "amavis ; 

$daemon group —- "clamav ; 

$mydomain - "pelda.org ; 

$MYHOME - "/var/amavis ; 
$OUARANTINEDIR —- "/var/fvirusoslevelek ; 
$db home — "$MYHOME/db"; 

$helpers home - "$MYHOME/var" ; 

$pid.file - "$MYHOME/var/amavisd.pid"; 
$1ock file -— "$MYHOME/var/amavisd.lock"; 


$1]og level — 2; 

$virus admin - "mická$mydomain" ; 

$mailfrom notify admin -— "antivirusá$mydomain" ; 
$mailfrom notify spamadmin —- "antivirus 

s Aa$mydomain" ; 


ítttít http: //ww. clamav . net/ 
[ clamaáAv-clamd  , 

V gask daemon, [/CONTSCAN f h NM n", 
"/usr/share/clamav/clamd.sock? ] , 

agr/v bok$/7, gr/v bFOUND$/ , 

gar/A.7"?: (?P!lInfected Archive) (.") FOUND$/ J], 


A rendszer ellenőrzése 

Mielőtt bármilyen további műveletnek nekifognánk, ellen- 
őrizzük a rendszert. A legegyszerűbb módszer az ellenőr- 
zésre az, hogy küldünk magunknak egy levelet, amelybe az 
alábbi karakterláncot helyezzük el. Ez nem egy valódi ví- 
rus, hanem az Eicar tesztaláírásnak nevezett karakterlánc: 


X50! PXGAP[4V PZX54(PA)7CC)73 $EICAR-STANDARD- 
ANTIVIRUS-TEST-FILE! $H4H" 


Ha minden rendben működik, az amavisd küldött az 
amavisd.conf $virus. admin beállításában megadott 
címünkre egy levelet, eredeti üzenetünk pedig az 
amavisd.conf $OUARANTINEDIR beállításában megadott 
karanténkönyvtárba került. 

Az ellenőrzés idejére erősen ajánlott a levelezési naplófájl 
végének elkülönítése. Adjuk ki tehát a 


tail -f /var/log/mai!l 


parancsot, így elkülöníthetjük a Postfix és az amavisd nap- 
lóüzeneteit. lapasztalatom szerint ez a leggyorsabb megol- 
dás az esetleges hibák felismerésére, főleg akkor, ha a ko- 
rábban javasolt módon növeltük az amavisd naplójának 
részletességét. 

Ne feledjünk legalább egy tiszta próbalevelet küldeni, ezzel 
ellenőrizhetjük, hogy a Postfix továbbra is képes-e a szűret- 
len levelek fogadására és továbbítására. 


A ClamAV adatbázisainak frissítése 
Már csak egyetlen, de nem kevésbé fontos dolog van hát- 
ra, mégpedig a ClamAV vírusaláírásokat tartalmazó adat- 
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3. kódrészlet A /etc/postfix/master.cf fájlhoz 
hozzáadandó sorok 


smtp-amavis unix - - y - 2 smtp 
-o smtp data done timeout-1200 
-o disable dns lookupszyes 

127.0.0.1:10025 inet n - n — - smtpd 


-o content filter- 

-o local recipient maps-z 

-o smtpd client restrictionsz 
-o smtpd helo restrictions-z 
-o smtpd sender restrictionsz 


smtpd. recipient restrictions-permit mynetworks, 
ss reject unauth destination 
-o mynetworks-127.0.0.0/8 
-o strict rfc821 envelopeszyes 
-o smtpd error sleep time-0 
-o smtpd soft error limit-1001 
-o smtpd hard error limit-1000 


bázisainak frissítése, illetve az ezt a műveletet napi rend- 
szerességgel végrehajtó cron munka megadása. A ClamAV- 
hez tartozik egy pontosan ilyen célra készült, freshclam 
nevű segédprogram. 

Mivel a freshclam az egész rendszer legegyszerűbb eleme, 
és gyakorlatilag a helyből is kifutottam, mindenkinek meg- 
hagyom az élményt, hogy maga fedezze fel a freshclam(1) 
és a freshclam.conf(5) súgóoldalakat. Annyit azért gyorsan 
elmondanék, hogy a hétköznapok során csupán a 


freshclam -] /naplófájl/elérési/útja 


parancsot kell használnunk, ahol a /naplófájl/elérési/ 
útja azt a fájlt adja meg, amelybe a freshclam a naplóüze- 
neteit írja. 

A freshclamet néhány óránként érdemes lefuttatni. A leg- 
egyszerűbb az, ha a freshclamet a -c és a -d kapcsolók segít- 
ségével démon módban használjuk. lovábbi tudnivalókat 
a freshclam(1) súgóoldalon találni. 


Összefoglalás 

Munkánk eredményeként egy ClamAV alapú védelem- 
mel felszerelt SMIP átjárót kaptunk, vagy legalábbis 
elindultunk az úton ennek megvalósítása felé. Akinek 
további kérdése maradtak, az az internetes források kö- 
zött Postfix és Amavisd-new oktatóanyagot egyaránt talál. 
Sok szerencsét! 


Linux Journal 2004. december, 128. szám 


Mick Bauer biztonsági szakember, 

a Linux Journal biztonsági témákkal foglalkozó 
szerkesztője, biztonsági tanácsadó a Minnesota 
állambeli Minneapolisban. A Building Secure 
Servers With Linux című kötet szerzője 

(O Reilly d Associates, 2002). 
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Cikkgyuújtés az Atom segítségével 


Szeretnénk mindenkinek udvarias értesítést küldeni a weboldalunkon megjelent 
új tartalomról? Valósítsuk meg a legújabb cikkgyűjtő szabvány támogatását, 
és újabb eszközt nyerünk látogatóink visszacsalogatására. 


szervezett bűnözés világában a szindikátus együtt 
AA dolgozó bűnözők csoportját jelenti. A sajtó világá- 

ban a szindikátus feladata az információk terjesz- 
tése az előfizetők felé, miközben minden kiadó testreszab- 
hatja a kapott információkat. A karikatúrákat, híreket és 
publikációkat gyakran szindikátusok terjesztik, így a szer- 
zők nagyobb közönséget érhetnek el, az olvasók pedig 
nagyobb tartalomválasztékból csemegézhetnek. 
Az elmúlt néhány évben a webes fejlesztők is átvették 
a szindikátus kifejezést, és egyből igeként és főnévként is 
használni kezdték. Szerencsére a weben a szindikátus sok- 
kal inkább a sajtó világában megszokott dolgot takarja, és 
nem sok köze van a mackósokhoz. Az viszont tény, hogy 
miként a szervezett bűnözés világában, a kapcsolódó nyil- 
vános viták során is jónéhány ember kapott súlyos sebeket 
(igaz, nem fegyverek, inkább szavak által), ami megosztott- 
sághoz és sok keserűséghez vezetett a webes szindikálás, 
cikkgyűjtés terén. 
A megosztottság eredménye az Atom nevű új cikkgyűjtő 
formátum, amely sokban egyezik az RSS-sel (Az RSS a , rich 
site summary" rövidítése. Használatos még az RDF site 
summary kifejezés is attól függően, hogy melyik változatról 
van szó és kit kérdezünk meg.) Én úgy vélem, hogy az 
Atom számos előnyt kínál az RSS bármely változatával 
szemben, és az Atom cikkek létrehozásának egyszerűsége 
egyértelműen előnyösebb választássá teszi az RSS-hez ké- 
pest. Figyelembe véve, hogy a legtöbb webnapló termék 
RSS cikkek előállítására képes, kijelenthetjük, hogy a két tá- 
bor békésen megfér egymás mellett. Érdemes viszont mind- 
két megoldás működését átlátni, hiszen így megalapozott 
döntést hozhatunk arról, hogy melyik - esetleg mindkettő — 
szabályrendszert kövessük. 


Égy kis történelem 

Mint a múlt hónapban láttuk, az RSS valójában két kü- 
lönböző formátum, vagyis inkább két különböző formá- 
tumcsalád. Az RSS 0.9x és az RSS 2.0 ugyanabba a családba 
tartoznak, és kiválóan szemléltetik a webes cikkgyűjtés fej- 
lődését. Az RSS 2.0-t elsősorban a Userland-tól Dave Winer, 
a scripting.com és újabban a Harvard University tartotta, 
tartja karban. Winer átadta a szabvány tulajdonjogát 

a Harvardnak, ám azt is kijelentette, hogy a 2.0 lesz az 
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utolsó változat. Van is benne valami, hiszen az RSS 0.9x és 
az RSS 2.0 együttesen széles körben elterjedt, üzembiztos, 
jól ismert - és a kissé zavaros — protokollt jelentenek 

a webes tartalmak összegyűjtésére. 

Létezik egy másik RSS-fajta is, neve a megtévesztő RSS 1.0, 
amely az erőforrás-fejlesztési keretrendszerre (resource 
development framework, RDF) épül, és amelyet a World 
Wide Web Consortium (W30) gondoz. Az RDF-et arra ter- 
vezték, hogy a számítógépek képesek legyenek megérteni 
a webhelyek tartalmát, ennek alapján képesek legyenek 
kapcsolatokat teremteni közöttük, pontosan úgy, ahogy az 
emberek is teszik ezt ösztönösen. Az RSS 1.0 összegzései 

a többi RSS-változattal nem használhatók, viszont az RDF 
alapján szabványos leírást nyújtanak a webhely tartalmáról. 
Abból, hogy az RSS 1.0 is az RSS nevet kapta, rengeteg vita 
és ellenségeskedés származott, sokan a legváltozatosabb 
módokon szidták Dave Winert, az RSS előírások bizonyta- 
lanságát és az Atom elődjének alkotóit. Végül néhány veze- 
tő személyiség — Tim Bray, Mark Pilgrim és Sam Ruby veze- 
tésével —olyan cégek támogatásával, mint például a Six 
Degrees (ez adja ki a Movable Iype webnapló programot) 
nekikezdett egy új szabálygyűjtemény kidolgozásának, 
amelyet eleinte PIE-nak majd Echonak hívtak, és amely 

az RSS gyengeségeinek kiküszöbölését célozta. 

Az Atom fejlesztése eltartott egy ideig, ugyanis első lépés- 
ként meg kellett határozni, hogy napjaink webje esetében 
pontosan mit is jelentsen a cikkgyűjtés. Az RSS-t immár 
nemcsak eredeti alkalmazói, a híroldalak használják, de sok 
webnapló és nem szöveges jellegű tartalmat szolgáltató ol- 
dal is támogatja. A fejlesztők úgy döntöttek, hogy a több- 
nyelvűségnek kiemelt szerepet szánnak, vagyis azt célozták 
meg, hogy a cikkeket tetszőleges nyelven lehessen szolgál- 
tatni. Ugyancsak nagy hangsúlyt kapott a bővítmények fej- 
lesztése, vagyis az Atomot úgy lehet új szolgáltatásokkal bő- 
víteni, hogy a fő Atom szabályokhoz nem kell hozzányúlni. 
Cikkem írásakor (2004. augusztusának közepén) az Atom 
szabálygyűjtemény 0.3-as változatban létezik, továbbá tar- 
tozik hozzá egy szabványos API is a hálózaton keresztül 
végzett tartalomszerkesztéshez. Az Atom elindult az IETF 
(Internet Engineering Task Force, ez a szervezet állítja össze 
és teszi közzé az internetes szabványokat) szabvánnyá vá- 
lás útján, vagyis hamarosan általánosan elfogadott szab- 


vány lehet, akár csak a TCP/IP, az SMIP vagy a HITP. 
Kétségtelen, hogy az Atom növekvő érdeklődésre számíthat 
azon szervezetek részéről, amelyek már csak az IETF jóvá- 
hagyó pecsétjére várnak. 

Az Atom továbbra is kezdeti állapotban van, számos elem- 
nek - például a bővítményeknek - hiányzik a nyilvános le- 
írása. Készítői ugyanakkor máris elmondhatják, hogy készí- 
tettek egy szabványt, amelynek összetettsége közel áll az 
RSS 0.9x és 2.0 előírásgyűjteményéhez, jól érhető és átte- 
kinthető, a webes cikkgyűjtő közösség komoly támogatását 
élvezi, valamint szemléletében messze túlmutat a puszta 
webes cikkgyűjtésen. 


Atom cikk létrehozása 

Míg az RSS-t elsősorban híroldalak és webnaplók bejegyzé- 
seinek összegyűjtésére tervezték, az Atom inkább általános 
célú megoldásnak készült. Lehet például olyan rendszert 
építeni, hogy egy üzem gépei állapotjelentésüket Atom for- 
mátumban készítik el, majd egy cikkgyűjtő ezek alapján jelzi 
a meghibásodásokat. Megoldható, hogy a könyvtárak Atom 
cikkeket készítsenek legújabb beszerzéseikről, a különféle té- 
mákkal kapcsolatos könyvek elérhetőségét pedig intelligens 
cikkgyűjtők figyeljék. Ilovábbi felhasználási terület a faxgé- 
pek faxmodemekre cserélése, majd a faxképek Atom alapú 
terjesztése a megfelelő személyek vagy csoportok felé. 

Az Atom akár szerkesztőségi rendszer összeállítására is alkal- 
mas lehet, ahol a tudósítók írásaikat nem elektronikus levél- 
ben, hanem Atom cikkek formájában küldik el. Mindegyik 
szerkesztő összegyűjtené az irányítása alá tartozó tudósítók 
Atom cikkeit, majd a szerkesztési munka befejezése után ki- 
menő Atom cikkekbe másolná őket. A cikkgyűjtés utolsó fá- 
zisa a tördelő részleg lenne, ahol előkészítenék a szövegek 
nyomtatását. Az újság tartalma tehát Atom cikkek áramlása 
révén állna össze, a végső cikk maga az újság lenne. 

Atom cikket előállítani rendkívül egyszerű, ha Perl-t vagy 
más magas szintű nyelvet használunk, amelyhez létezik 
Atom könyvtár. A Perl esetében például az XML::Atom mo- 
dullal tudunk dolgozni, amely a CPAN-ról tölthető le. Ne- 
kem Fedora Core 2 alatt, a Perl 5.8.3-as változatával volt né- 
mi gondom az XML::Atom telepítésével, ezt úgy tudtam 
megoldani, hogy az elhagyható DateTime modult kivettem 
a telepítésből. Éles környezetben ezt a megoldást nem 
javaslom. 

Bár a teljes csomag neve XML : : Atom, az Atom cikkeket elő- 
állító programok valójában az XML : : Atom: : Feed és az 

XML : : Atom: : Entry modult használják. Példaként lássunk 
egy rövid Perl programot, amely egy egyszerű cikket állít 
elő, és amely részben az XML : : Atom: : Feed internetes 
perldoc leírásában szereplő példaprogramra alapul: 


t1!/usr/bin/per1 
use strict; 
use diagnostics; 


use warnings; 


use XML ::Atom: : Feed; 
use XML ::Atom: : Entry; 


ft Új Atom cikk létrehozása 


www.linuxvilag.hu 


my $feed -— XML::Atom: : Feed-snew; 
$feed-stitle( webnaplóm ); 


my $entry; 

f A cikk első bejegyzésének létrehozása 
$entry - XML::Atom::Entry-snew; 
$entry-stitle( Első írás ); 
$entry-scontent( Első írás törzse ); 
$feed-sadd entry($entry); 


f A cikk második bejegyzésének létrehozása 
$entry - XML::Atom::Entry-snew; 
$entry-stitle( Második írás ); 
$entry-scontent( Második írás törzse ); 
$feed-sadd entry($entry); 


ft Az XML kimenet előállítása 
my $atom feed xm] - $feed-sas xml; 


f Az XML kimenet megjelenítése 
print $atom feed xml, "WV n7; 


A fenti program az alábbi cikket állítja elő, amelyet 
a könnyebb olvashatóság kedvéért kicsit átformáztam: 


c?xm] version-71.0775 
cfeed xmlns-"http://purl.org/atom/ns$"5 
ctitles 
webnaplóm 
c/titles 
centry 
xmilns:default-"http://www.w3 . org/1999/xhtmlI "5 
ctitles 
Első írás 
c/titles 
ccontent mode—"xml"s 
cdefault:div 
s xmlns-"http://ww. w3 . org/1999/xhtmI 7": 
Első írás törzse 
c/default:div: 
ca/contents 
c€/entryz 
centry 
xmilns:default-"http://www.w3 . org/1999/xhtmlI "5 
ctitles 
Második írás 
c/titles 
ccontent mode—7xml"s 
cdefault:div 
s xmlns-"http://ww. w3 . org/1999/xhtmlI 7": 
Második írás törzse 
c/default:div: 
ca/contents 
c€/entryz 
c/feeds 


Mint láthatjuk, létre kell hoznunk egy XML : : Atom: : Feed 


objektumot, amibe az XML : : Atom: : Entry egy vagy több 
példánya kerül. Az Atom cikken belül minden bejegyzés 
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objektum egy-egy centry: címkével párosul, ezek pedig 
egy-egy üzenetet jelenítenek meg webnaplónkból vagy 
éppen az üzem felügyeleti rendszeréből. 

Az Atom szabálygyűjtemény szerint a cikk számos jellem- 
zőt és alelemet is magába foglalhat, ilyen például a nyelv, 

a webnapló vagy webhely leírása, a szerzői jogi megjegyzé- 
sek és a származási hellyel kapcsolatos egyéb tájékoztatá- 
sok. Az egyes bejegyzések ugyanakkor saját elemkészlettel 
rendelkeznek, mint például cím, létrehozás időpontja és 
összegzés. Minden Atom elemnek van egy MIME típusa, 
amely a tartalom jellegéről tájékoztat, hasonlóan a HITP- 
válaszokhoz és az elektronikus levelek mellékleteihez. 
lermészetesen cikk létrehozására a fenti módon csak akkor 
van szükség, ha új Atom-képes alkalmazást írunk, vagy sze- 
retnénk ilyen irányba bővíteni meglévő webnapló alkalma- 
zásunkat. A legtöbb webnapló termék már most is képes 
Atom cikkek előállítására, akár a normál csomag részeként, 
akár valamilyen beépülő modul vagy egyéb bővítmény ré- 
vén. A Blosxom Weblog rendszerhez például beépülő mo- 
dul készült, segítségével könnyedén megoldható az Atom 
cikkek előállítása. A beépülő modult egyszerűen csak be 
kell másolni a plugins könyvtárba, és ettől kezdve bárki 
kaphat Atom cikkeket a kérdéses webnaplóról. 

Remélem, nem okozott meglepetést, hogy mindez ennyire 
egyszerű, ugyanis a Blosxom Perlben íródott, a Perl pedig ki- 
váló eszközöket kínál az XML kezelésére, a beépülő modul- 
nak pedig csak annyi a dolga, hogy összesítse és újraírja 

a webnapló legújabb bejegyzéseinek tartalmát. Abból, hogy 
a Blosxom ennyire könnyűvé teszi a beépülő modulok szá- 
mára a főoldal módosítását (ahogy az Atom cikk megjelené- 
sének jelzését is) és a tartalom lekérdezését (a beépülő mo- 
dul API-n keresztül), egyenesen következik, hogy alóla 
rendkívül könnyű az Atommal dolgozni. Mivel a legtöbb 
webnapló program magas szintű nyelven, tehát Perlben, 
Pythonban vagy PHP-ban készül, az Atom kezelésének meg- 
valósítása még nulláról kezdve sem okozhat nehézséget. 


Atom cikk feldolgozása 

Az Atom cikkek feldolgozására rengeteg módszer közül 
választhatunk, akár cikkgyűjtőt szeretnénk írni, akár Atom 
alapú alkalmazást szeretnénk készíteni. A legegyszerűbb 
megoldás a cikkek felfedezésére és lekérdezésére továbbra 
is az XML : : Atom: : Feed használata. Például: 


$1!/usr/bin/per1 


use strict; 
use diagnostics; 
use warnings; 


use XML ::Atom: : Feed; 


ítt A ww.diveintomark.org Atom cikkeinek 
ft lekérdezése 
my duris - 
XML : : Atom: : Feed-:find feeds( 
"http: //ww. diveintomark.org/") ; 


f Az egyes Atom cikkekhez tartozó URI-k 
ft kiírása 
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foreach my $uri (C(duris) 
t 
print "uri — ($uriV n"; 
J 


A fenti példával egyszerűen meg tudjuk jeleníteni az URI- 
kat. Most, hogy már tudjuk, hol keressük az egyes cikkeket, 
elő tudjuk állítani a bennük szereplő hivatkozások listáját, 
majd a hivatkozásokat XML formára tudjuk hozni: 


$1!/usr/bin/per1 

use strict; 

use diagnostics; 

use warnings; 

use XML ::Atom: : Feed; 

ff Atom cikk lekérése 

my Guris - XML::Atom:  :Feed-s 


find feeds( "http://ww. diveintomark.org/") ; 


foreach my $uri (C(duris) 


1 
my $feed -— XML::Atom: :Feed-:new(URI-:new($uri) ) ; 


my alinks - $feed-slinkO; 


foreach my $link (Alinks) 


í 
my $link xmil - $l]link-sas xmIO; 
print "Tink — "$link xmiV n7; 
s 
A 


at 


lermészetesen XML-t nem állítunk elő és nem jelenítünk 
meg, a lényeg a hivatkozások kinyerése, amelyeket elektro- 
nikus levélben el tudunk küldeni az előfizetőknek, hozzá 
tudunk adni a megfelelő adatbázishoz, de akár el is hagy- 
hatjuk közülük az adott feltételeknek meg nem felelőket. 
Mivel az Atom cikkek szabályos felépítésűek, illetve inter- 
netes szabványokra alapulnak, mint az XML, az Unicode és 
a MIME, biztosak lehetünk abban, hogy a cikkből kiemelt 
tartalmat egyszerű módszerekkel tudjuk kezelni. A különfé- 
le tartalomtípusokat különféle kezelőprogramoknak továb- 
bíthatjuk, különféle módszerekkel dolgozhatjuk fel (akár- 
csak a korábban említett szerkesztőségi rendszerben) vagy 
új cikkekbe másolhatjuk őket, így akár egy , szupercikk- 
gyűjtőt" is létre tudunk hozni. 

Aki szeretne cikkgyűjtőt készíteni, vagy szeretne pontosabb 
képet alkotni arról, hogy a millióféle RSS- és Atom-változatok- 
kal hogyan tud dolgozni, annak érdemes megismernie Mark 
Pilgrim cikkgyűjtőjét. A program Python alapú, szerzője fo- 
lyamatosan frissíti, és talán ez a legjobb leírással ellátott nyílt 
forrású motor a cikkgyűjtő rendszerek anyagainak kezelésére. 


RSS vagy Atom? 

A fő kérdés: weboldalunk -— vagy éppen webnaplónk - az 
RSS vagy az Atom formátumú cikkgyűjtést támogassa, eset- 
leg mindkettőt? Számomra egyértelmű, hogy az Atom a leg- 


jobb a napjainkig kidolgozott kettő (pontosabban három) 
cikkgyűjtő formátum közül. Dave Winer RSS formátumai 
megjelenésükkor komoly újdonságnak és előrelépésnek 
számítottak, ám túl sok hibájuk volt ahhoz, hogy egy teljes 
értékű, akár vállalati környezetben is használható szab- 
vány alapját adják. A HTML és a JavaScript korai változata- 
inak példáján láthattuk, hogy a félkész szabványok csak 
kínlódást hoznak, és figyelembe véve, hogy a cikkgyűjtés 

a jövőben jó eséllyel rendkívül fontos kommunikációs 
módszerré válik, a teljesség és az egyértelműség alapköve- 
telménynek számít. 

Hasonlóan fontos a különféle nyelvek támogatása, valamint 
azt sem szabad elfeledni, hogy az emberek nem csak szöve- 
geket szeretnének közzétenni. Az Atom egyértelműsége 

a különleges karakterek kezelése tekintetében szintén 
hangsúlyos tényező, ennek köszönhetően biztosak lehe- 
tünk abban, hogy ha elhelyezünk a webnaplónk szövegé- 
ben egy c and : elemet, akkor ezzel nem fogjuk megzavarni 
a cikkgyűjtés működését. A legfontosabb talán mégis is, 
hogy a tervezett bővítési lehetőségek révén az Atom bár- 
mely különleges csoport vagy alkalmazás igényeinek képes 
lesz megfelelni úgy, hogy magát az alapot nem kell majd 
módosítani. 

Az Atom rendkívül sokoldalú, használata mégis egyszerű, 
ennek fejlesztése során is nagy figyelmet szenteltek. Egy új 
API-t létrehozni nem egyszerű, különösen, ha a lehető leg- 
inkább általános jellegűnek kell lennie. 

Végül megjegyeznék annyit, hogy az RSS változatszámok 
kavalkádja, amely kicsinyes és szinte már a politikára emlé- 


keztető vitákat szült — miközben maga a kavalkád is ezek- 
nek a vitáknak köszönhetően alakult ki — gyakorlatilag sen- 
kinek nem vált hasznára. Az Atom különböző nevet kapott, 
és bár ennek a névnek homályos a jelentése, legalább nem 
súlyosbítja a fejlesztők és a felhasználók oldalán az RSS mi- 
att kialakult félreértéseket. 


Osszefoglalás 

Az Atom révén esélyt kaptunk az RSS kapcsán felmerült 
gondok megoldására, illetve arra, hogy a cikkgyűjtés újfaj- 
ta, internetes alkalmazások között folyó, magas szintű adat- 
csere megoldások alapjává válhasson. Az Atom némileg bo- 
nyolultabb Dave Winer RSS-változatainál, ám - legalábbis 
első változatát tekintve — egyszerűbb, mint a webhelyek le- 
írását és tartalmuk összesítését az RDF alapján végző RSS 
1.0. Az Atom cikkek kezelését leegyszerűsítő, könnyen hasz- 
nálható segédeszközök, a bővíthetőség és a szerzőknek az 
internetes szabványokra fordított figyelme egyértelművé 
teszik, hogy az Atom fontos szerepet fog játszani a webes 
kommunikáció jövőjében. 


Linux Journal 2004. november, 127. szám 


Rewven M. Lerner (5 http:/Avww.lerner.co.il/atf) 
Nyílt forrású programokra, valamint web- és adat- 
bázis-alkalmazásokra szakosodott tanácsadó. 
Könyve, a Core Perl, 2002 januárjában jelent meg 
a Prentice Hall gondozásában. Reuven feleségével 
és lányaival nemrég költözött Chicagóba. 





www.linuxvilag.hu 


2005. január 46 


GŐ4///V, SZZSSSSZEE szaktekintély 


0 Kiskapu Kft. Minden Jog fenntartva 











(Ö 
Bs 
h 
1 
40 
7 
e 
za 
DD 
4— 
0) 
ee 
Éz 
DD 
"OO 
s 
sz 
al 
4— 
Ms 
-J 
6.8 
40 
az 
s 
Ms 
o 


Filmszerkesztés a Kino-val 


Napjaink olcsó videokamerái kiváló felvételeket készítenek. Ha Igazi filmeket 
szeretnénk előállítani, akkor csupán a megfelelő szerkesztőeszközökre és 


persze gyakorlatra van szükségünk. 


inden videokamera-tulajdonosban felvetődött 
már a gondolat, hogy nyers felvételeit átszer- 
kesztve valamilyen igazi filmet is készíthetne. 
Maga a kamera hiába tud számtalan különleges hatást, 
szerkesztőeszközökre mindenképpen szükségünk lesz. 
Szerencsére a manapság kapható nagyteljesítményű 
számítógépekkel, a Linuxszal és a Kino nevű alkalma- 
zással könnyedén összeállíthatjuk saját kis hollywoodi 
stúdiónkat. 

A Kino egy nemlineáris szerkesztőprogram. Képes a nyers 
felvételek rögzítésére, szerkesztésére és átrendezésére, vala- 
mint a végeredmény átalakítására és mentésére. A további 
ingyenes beépülő modulok révén a Kino minden olyan esz- 
közt a kezünkbe ad, amelyre jó filmek szerkesztéséhez 
szükségünk lehet. 

A filmkészítés általában a nyersanyag kamerás felvételével 
kezdődik. Ezzel a résszel nem foglalkozunk, a munkát 

a nyers felvétel számítógépre másolásának fázisától tárgyal- 
juk. A korszerű kamerák a számítógépekkel IEEE 1394 felü- 
leten keresztül kommunikálnak, ezt az Apple FireWire, 

a Sony pedig i.Link névvel is illeti. Az átmásolás után lehe- 
tőségünk nyílik a mozgókép szerkesztésére, valamint fel- 
iratokat és hatásokat adhatunk hozzá. A filmszerkesztés 

a hangok hozzáadására, keverésére és lecserélésére is kiter- 
jedhet. A Kino az összes ilyen feladat elvégzésére alkalmas. 
Ha elkészült a film, felírhatjuk DVD-lemezre, így különálló 
DVD-lejátszóval is meg tudjuk nézni, de MPEG4 fájlt is ké- 
szíthetünk belőle. A tömörített fájlok minősége elmarad az 
eredeti felvételekétől, ha tehát valóban kiváló minőségre 
vágyunk, és digitális kameránk tudását tökéletesen ki sze- 
retnénk használni, akkor a filmet a Kino és a kamera segít- 
ségével DV szalagra is visszaírhatjuk. 





A szükséges hardvereszközök 

A videófolyam kamera és számítógép közötti továbbításá- 
hoz mindkét oldalon egy IEEE1394 csatolóra van szükség. 
Nézzük át gépünket, sok korszerű számítógép, ide értve 

a hordozhatókat is, rendelkezik ilyen csatolóval. Ha nincs 
ilyen a gépünkben, különálló IEEE1394 kártyát kell vásárol- 
nunk, ilyet számos gyártó választékában találunk. Nyilván 
egy digitális videokamerára is szükségünk van, ez Digital8 
(röviden D8) vagy MiniDV rendszetű egyaránt lehet. 


ü 
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1. ábra A Kino főablaka indításkor 





A számítógép és a kamera összekötésére kell még egy kábel. 
A kamerákon általában négy érintkezős mama csatlakozó 
van, a számítógépeken pedig hat érintkezők csatlakozókat 
találunk. Vessünk tehát egy pillantást a két készülékre, majd, 
ha még nincs ilyenünk, vegyünk egy 4-4 vagy 4-6 kábelt. 
Mondani sem kell, számítógépünknek nagy kapacitású me- 
revlemezzel kell rendelkeznie, amin nagy mennyiségű sza- 
bad helyet kell biztosítanunk. Ha például egy 60 perces 
MiniDV kazetta tartalmát szeretnénk a számítógépre másol- 
ni, akkor 12 GB helyre lesz szükségünk. A szerkesztéshez, 
a képek és hangok tárolására 15 GB-tal számolhatunk, va- 
gyis egy órányi nyers felvételből 27 GB-nyi helyen tudunk 
filmet vágni. Attól függően, hogy mit szeretnénk végered- 
ménynek, további 14 GB-ra lesz szükségünk, ha a filmet 
egy új .dv fájlba szeretnénk kiírni. Az átmásolás idején 

a számítógépnek másodpercenként nagyjából 3,5 MB ada- 
tot kell rögzítenie, tehát a merevlemez a lehető leggyorsabb 
legyen. Megfelelő beállításokkal bármelyik korszerű liltra- 
DMA meghajtó megfelel. 

1 GHz órajelű processzor és 128 MB memória nélkül 

neki se kezdjünk a műveletnek, de ha kényelmesen aka- 
runk dolgozni, akkor több memóriával és erősebb pro- 
cesszorral számoljunk. 


e TT 


A szükséges programok 

A programok listája a Kino-val és az általa igényelt könyv- 
tárakkal kezdődik, de itt korántsem ér véget. A Kino csak az 
alapvető szerkesztőeszközöket biztosítja, és csupán néhány 
hatást támogat. Tim Shead és Dan Dennedy fejleszti a timfx- 
et, mely további hatások beépítését segítő Kino beépülő mo- 
dulok gyűjteménye. A feliratok, címek hozzáadásához egy 
további beépülő modul szükséges, az Alejandro Sierra által 
fejlesztett dotitle. 

Mivel a Kino további programokat és könyvtárakat is igé- 
nyel, forrásból való telepítése bizony nem egyszerű feladat. 
A Kino egységes csomagként számos terjesztés — Debian, 
SuSE és Fedora - alá érhető el. A megfelelő csomag telepíté- 
se jóval egyszerűbb, mint a forrással bajlódni. 

A Kino fejlesztése rendkívül jó tempóban halad. Cikkünk 
írásakor a legújabb változat a 0.7.3. A Debian 3.0 üzembiztos 
kiadásban a Kino 0.5.0, a Debian 3.1-ben (fejlesztői ág) 
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2. ábra A Kino ablaka rögzítés után 


a 0.7.3, míg a SuSE 9.1-ben a 0.7.0 változat szerepel. A prog- 
ramok naprakészen tartásához minden szükséges csomag 
rendelkezésünkre áll. 


Nyers felvétel átmásolása számítógépre 

Miután telepítettük a programokat, az IEEE1394 felületen 
keresztül csatlakoztassuk kameránkat a számítógéphez, 
majd tetszőleges X terminálon vagy a KDE vagy a GNOME 
Alt-F2 párbeszédpaneljéről adjuk ki a kino parancsot. 

A Kino nyitóképernyője jelenik meg, mely az 1. ábrán látha- 
tóhoz fog hasonlítani. 

A grafikus felületet könnyű átlátni. Mozgókép rögzítéséhez 
válasszuk a jobb oldalon lévő Capture (Rögzítés) fület. A fel- 
vétel elindítása előtt azonban érdemes ellenőrizni a beállítá- 
sokat. Az alapértelmezett beállításokat az Edit-: Preferences 
(Szerkesztés- : Beállítások) paranccsal érhetjük el. 

A Normalisation (Normalizálás) , Audio (Hang) és Aspect 
Ratio (Képarány) beállítást a kamerának megfelelően állít- 
suk be. A pontos beállítások a kamera mellett attól is függe- 
nek, hogy a világ mely tájékán élünk. Az USA, Kanada 

és Japán területén az NISC, míg a világ többi részén 

a PAL szabványt használják. A kamerák általában kétféle 
hangmódot ismernek, a 16 és a 14 biteset. A legtöbb 
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esetben az előbbi az alapbeállítás. A felvétel elindítása 

előtt ezt is állítsuk 16 bitre, így jobb minőséget kapunk. 

A felvett mozgóképet háromféle formátumba menthetjük, 
.dv és kétféle .avi formátumot választhatunk. Általában 
mindegy, melyiket használjuk, de inkább maradjunk 

a nyers DV-nél. 

Ha végeztünk a beállítások megadásával, kattintsunk 

a Capture gombra, majd - kiterjesztés nélkül - írjuk be a fel- 
veendő mozgóképet tároló fájl nevét. Ha gondoljuk, kap- 
csoljuk be Az Auto Split Files (Fájlok önműködő vágása) 
szolgáltatást, ez az általa felismert jelenetváltásoknál új, az 
általunk megadott névvel és egy sorszámmal elnevezett 
fájlt kezd. A többi beállításnál nyugodtan meghagyhatjuk 
az alapértéket. 

Következő lépésként rá kell vennünk a kamerát a vezérlője- 
lek fogadására. A kamerák ezt jellemzően lejátszás módban 
tudják, de ha bizonytalanok vagyunk, olvassuk át a kamera 
leírását. Próbáljuk ki, hogy tudjuk-e a Kino-val vezérelni 

a kamerát. Próbáljuk meg előre-hátra csévélni a szalagot. 
Ezután kattintsunk a program Play (Lejátszás) gombjára. 
A lejátszásnak el kell indulnia, a felvételnek a Kino főabla- 
kában és a kamera kijelzőjén is meg kell jelennie. Figyeljük 
az Eldobott képkockák (Dropped frames) mező értékét. El- 
méletileg itt nullának kell megjelennie, de akkor sincs baj, 
ha az első egy-két képkocka elvész. Ha viszont az eldobott 
képkockák száma folyamatosan növekedik, akkor vagy las- 
sú a számítógép, vagy elállítottunk valamit. Ha a kamerát 
nem tudjuk vezérelni a Kino-val, akkor próbáljuk kézzel 
betölteni a raw1394 illesztőprogramot. Ehhez a modprobe 
raw1394 parancsot kell kiadnunk. 

Ha gépünk túl lassúnak bizonyul, akkor próbáljuk ki 

a dvgrab nevű, digitális videó rögzítésére alkalmas parancs- 
sori programot. A dograb a Kino honlapjáról érhető el. 
Használata előtt lépjünk ki az X-ből, majd kövessük a hoz- 
zá tartozó man oldalon foglalt utasításokat. A nyers felvétel 
rögzítése után indítsuk el a Kino-t, és az alábbiakat követve 
töltsük be szerkesztésre a felvételt. 

Ha a lejátszás jól működik, nekiláthatunk a rögzítésnek. 
Léptessünk 1-2 másodperccel a rögzíteni kívánt rész 

elé, majd kattintsunk a Capture gombra. A Kino elindítja 
a kamerát, és rögzíti a felvételt. A rögzítést bármikor 
leállíthatjuk, ha rákattintunk a Stop gombra. Az átvitt 
mozgókép a jelenetlistában tűnik fel, a Kino ablakának 
baloldali részén. Az AutoSplit szolgáltatás időnként hi- 
básan működik, ám ezeket a hibákat később ki tudjuk 
küszöbölni. A Kino ablakának rögzítés utáni állapotát 
láthatjuk a 2. ábrán. 

Amint végeztünk a rögzítéssel, válasszuk a File (Fájl) me- 
nü Save (Mentés) parancsát, és egy SMIL (Synchronized 
Multimedia Integration Language, szinkronizált multimé- 
dia integrációs nyelv) fájl formájában mentsük el terveze- 
tünket. Az 1. kódrészlet egy SMIL példát tartalmaz. 

A cseg: és a c/seg: címke között mozgóképek leírá- 

sai találhatók. Mindegyik egy egyszerű vagy összetett 
jelenetet ad meg. Az egyszerű jeleneteket egy-egy 
cvideo. . .5 címke írja le, ez a filmben felhasználandó 
szakasz első és utolsó képkockájára mutat. Az összetett 
jelenetek egyszerű jelenetek halmazai. A jelenetek el- 

ső képkockája a Kino Storyboard (Forgatókönyv) bal 
oldalán jelenik meg. 
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1. kódrészlet Példa .smil filmtervezetre 


c?xm] version-"1.0"?s 


csmil xmins:smi1l2-"http://ww.w3 . org/2001/SMIL20/Language": 


csegz 


cvideo src-"/mnt/RAW FILES/Paris001.dv" clipBegin-"0" clipEnd-"441"/5 


c/segz 
csegz 
cAvideo src-"/mnt/RAW FILES/Par1s5002.dv" 
c€/segz 
csegz 
aAvideo src-"/mnt/RAW FILES/Paris003.dv" 
video src-"/mnt/RAW FILES/Paris004.dv" 
cvideo src—-—"/mnt/RAW FILES/Par1s5008.dv" 
c€/segz 
csegz 
cvideo src—"/mnt/RAW FILES/Par1s5004.dv" 
c€/segz 
c/smilz 


Ha a filmet több különböző szalagról állítjuk össze, akkor 
helyezzük be a következőt a kamerába, majd ismételjük 
meg a fenti lépéseket. 

A forgatókönyv az egyes jelenetek első képkockája mellett 
további hasznos adatokat is tartalmaz, így például a jelene- 
teket tároló fájlok nevét, továbbá a jelenetek kezdő időpont- 
ját és hosszát. 

Rögzítés közben a Kino az eredeti forrás szerinti időt jelení- 
ti meg, szerkesztés közben viszont a futó film ideje látható. 
Az idő kijelzése többféle formátumban is történhet. A leg- 
egyszerűbb a keret formátum, ez egy nulláról induló keret- 
számlálót mutat. Az emberi gondolkodáshoz közelebb áll 

a másodperc és perc alapú mérés, természetesen ilyet is 
választhatunk. Ha gondoljuk, használhatjuk a Society of 
Motion Picture and Television Engineers (SMPTE, Mozifilm 
és Televíziós Mérnökök Szervezete) időkód formátumát is, 
amely egy pontosvesszővel elválasztva az időt és a keret- 
számot egyaránt tartalmazza. Ha például a 00:07:40,15 idő- 
kijelzést látjuk, akkor 7 percnél, 40 másodpercnél és 15 kép- 
kockánál járunk. A nekünk tetsző időformátumot a Time 
(Idő) legördülő menüből választhatjuk ki. 


A film szerkesztése 

Mozart állítólag soha nem készített vázlatokat, ám nem le- 
het mindenki Mozarthoz hasonló. Ha a rögzítést túl korán 
kezdjük, netán túl későn állítjuk le, akkor a jelenetet meg 
kell vágni, ellenkező esetben hibás, szükségtelen, a kívánt 
időn túlnyúló részek lesznek a filmben. Egy-egy jelenet 
hosszát általában a cselekmény határozza meg. Ha nincs 
cselekmény, akkor a jelenet ne legyen 4-6 másodpercnél 
hosszabb. Az ennél rövidebb jelenetek villanásoknak hat- 
nak, a hosszabbak viszont unalmasak. 

A szerkesztés megkezdéséhez tekintsük át a jeleneteket. Ha 
egy jelenetben csak néhány felesleges kockát találunk, ak- 
kor egyszerűen töröljük őket. Ha az önműködő vágás hibá- 
zott, akkor a kérdéses részt egy másik jelenethez is áthe- 
lyezhetjük. Ha el akarunk távolítani egy jelenetet, kattint- 
sunk a jobb oldalon található Edit (Szerkesztés) fülre, a for- 
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clipBegin-"07" clipEnd-"368"/5 


clipBegin-"28" clipEnd-"761"/5 
clipBegin-"567" clipEnd-"967"/5 
clipBegin-"28" clipEnd-"761"/5 


clipBegin-"26" clipEnd-"234"/5 


gatókönyvben mutassunk 
a törlendő jelenetre, majd 
kattintsunk rá. A főablak- 
ban a jelenet első képkocká- 
ja tűnik fel. Kattintsunk az 
eszköztár olló ikonjára. 

A jelenet törlődik a forgató- 
könyvből, és a következő 
jelenet első képkockája 
tűnik fel a tőablakban. 
Sokszor szükség támad arra, 
hogy áttekintsük egy-egy 
jelenet egyes képkockátt. 

A Kino használatakor ezt az 
Idővonalra (Timeline) kattint- 
va tehetjük meg. A 3. ábrán 

a Kino idővonala látható. 
Ha egy jelenetnek csak egy 
részét akarjuk kivágni, ak- 
kor szükséges és szükségte- 
len részekre kell szétoszta- 
nunk. Ezeket az átvitelve- 
zérlő vonallal kereshetjük meg és tekinthetjük át. Ha az esz- 
közkészlet szétvágás ikonjára kattintunk, az éppen kiválasz- 
tott képkockával új jelenet kezdődik. Ügyeljünk arra, hogy 
az aktuális képkocka a Cut (Kivágás) paranccsal törölni kí- 
vánt jelenetben legyen. A módszer elsősorban akkor hasz- 
nálható jól, ha egy jelenet középső részét szeretnénk eltávo- 
lítani. Ha pontosan be akarjuk állítani egy jelenet kezdetét 
vagy végét, akkor inkább a Irim (Vágás) módot használjuk. 


Metszés 

A metszés rendkívül hasznos művelet. Alapvetően egy-egy 
jelenet első és utolsó képkockájának pontos kivágására 
használható. A metszés használatához válasszuk ki a jelene- 
tet a forgatókönyvben, majd kattintsunk a Irim fülre. Egy 
csúszka és két szövegdoboz jelenik meg, a bal oldali az In 
(Bemenet), a jobb oldali pedig az Out (Kimenet) felirattal, 
ahogy az a 4. ábrán is látható. A dobozokban a mozgókép- 
fájl aktuális jelenetének kezdő és záró pillanatához tartozó 
képkockák száma jelenik meg. A vezérlőgombokkal vagy 

a csúszka segítségével mozogjunk az új kezdő pozícióra. 
Az egy-egy képkockával dolgozó funkciók révén tökéletes 
pontossággal léptethetünk. Ha megvan az új kezdő pilla- 
nat, a pozícióváltáshoz kattintsunk a vonal alatti három- 
szögre. Az In szövegdoboz megváltozása visszajelzi a kivá- 
lasztást. A jelenet végét hasonló módszerrel jelölhetjük ki, 
végleges beállításához kattintsunk a jobb oldali háromszög- 
re. Ha elégedettek vagyunk az eredménnyel, kattintsunk 

a piros színű Apply (Alkalmaz) gombra. 

A program akkor is életbe lépteti a módosításokat, ha 
kilépünk metszés módból vagy másik jelenetet válasz- 
tunk ki a forgatókönyvből, ezért legyünk óvatosak 
szerkesztés közben. 

Az In mutató alatt egy szövegmező jelzi az aktuális metszé- 
si módot. Kétféle ilyen mód van, az Insert (Beillesztés) és az 
Over write (Felülírás) , ezek a szövegszerkesztőknél megszo- 
kott módon használhatók. A felülírás használatakor a forga- 
tókönyv éppen kiválasztott jelenetének helyét az új veszi 
át, a beillesztés választásakor pedig az új jelenet az éppen 
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3. ábra Jelenet áttekintése az idővonal segítségével 
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4. ábra A metszés használata 


kiválasztott elé vagy mögé kerül. A beillesztés módnak 
nincs Apply gombja, csak Before (Elé) és After (Utána) ikon- 
ja. A módosítások érvénybe léptetéséhez a megfelelő gomb- 
ra kell kattintani. 


A jelenetek sorrendezése 

Ha az összes jelenetről és epizódról levagdaltuk a felesleges 
részeket, megfelelő sorrendbe kell rendeznünk őket. Ezt leg- 
egyszerűbben a forgatókönyv segítségével tehetjük meg. Elő- 
ször kattintsunk az Edit (Szerkesztés) fülre, majd kattintsunk 
a forgatókönyv áthelyezni kívánt jelenetére, végül a Cut (Ki- 
vágás) parancsra. Válasszuk ki, hogy melyik jelenet legyen 

a kivágott mögött, majd kattintsunk a Paste (Beillesztés) pa- 
rancsra. A kivágott jelenet a kiválasztott előtt jelenik meg. 
Még könnyebb a jelenetek átrendezése a fogd és vidd mód- 
szer használatával. Szerkesztés módban kattintsunk az át- 
helyezendő jelenetre, tartsuk lenyomva az egér gombját, 
majd húzzuk a forgatókönyv kívánt pozíciójára a jelenetet. 
Az egérgomb felengedése után a jelenet ezen a helyen tű- 
nik fel. Húzás közben figyeljük az aktuális célpozíciót jelölő 
vékony vonalat. A fogd és vidd módszer nem működik, ha 
a cél pontozott téglalapként jelenik meg. Folyó filmterveze- 
tünkbe korábban rögzített mozgóképeket is beilleszthetünk. 
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b Propertlés 





A Commands/Insert Movie (Parancsok/ Film beillesztése) 
gombbal a kiválasztott filmet az aktuális pozícióra illeszt- 
hetjük be, a Commands/Append Movie (Parancsok/ Film hoz- 
záfűzése) gombbal pedig a végére. A beillesztett fájlokat 

a program kérésünkre azonnal jelenetekre osztja. 


Jelenetek összekapcsolása hatásokkal 

Ha összeállítottuk a jeleneteket, akkor a film mozgókép ré- 
sze majdnem kész, ám, ha gondoljuk, a Kino vagy a timfx 
hatásainak egy részét is beledolgozhatjuk. A hatásokkal 
bánjunk módjával, ha túlságosan sokat szórunk el a film- 
ben, az zavarja a nézőket. Nem muszáj az összes jelenetvál- 
tásnál hatást alkalmazni. Gondoljunk arra, hogy ha készí- 
tünk egy dokumentumot, annak sem írjuk minden bekez- 
dését másik betűtípussal. A legegyszerűbb Kino hatás 

a Barn Door (Kétszárnyú ajtó). Próbáljunk vele összekap- 
csolni két jelenetet. 
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5. ábra A Kino kétszárnyú ajtó hatásának használata — a hatás 
előnézete egy külön ablakban jelenik meg 


Kattintsunk az EX-: Video Iransition (EX-: Videoátmenet) 
parancsra. A legördülő menüből válasszuk a Barn Door 
Wipe (Kétszárnyú ajtó átúsztatás) elemet. A másik mezőben 
válasszuk ki a kívánt ajtótípust. Az 5. ábrán egy függőleges 
típus látható. A forgatókönyvben megjelenik az aktuális, 

a következővel összefűzendő jelenet első képkockája. 
Válasszuk a Frames following (Következő képkockák) és 

a Forward (Előre) parancsot. A leképezés előtt a Preview 
(Előnézet) gombbal nézhetjük meg az eredményt. Játsszunk 
el a hatás beállításaival is, és vizsgáljuk meg a leendő vég- 
eredményt. Ha elégedettek vagyunk, kattintsunk a Render 
(Leképezés) gombra. 

A Render gomb piros jelölése is fontosságát jelzi. Leképezés 
közben a Kino egy új fájlt állít elő. Minden eddigi módosí- 
tás az eredeti fájlokat érintetlenül hagyja, csak a SMIL fájlt 
érinti. Most azonban új fájl jön létre, ami azonnal be is ke- 
rül a tervezetbe. 

Az ajtós hatást a Kino maga tartalmazza, további hatásokat 
a timfx révén érhetünk el. A 6. ábra a hatások teljes listáját 
tartalmazza. Ezek jelentős része széles körben ismert, ilyen 
a feliratok kapcsán hamarosan szóba kerülő is. 

A Kino a film sebességét is képes megváltoztatni. Ezzel a le- 
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hetőséggel vicces hatásokkal bővíthetjük a filmet, illetve 
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7. ábra A Video Transition (Videoátmenetek) menü 


egyes pillanatokat meghosszabbíthatunk. A sebesség módo- 
sításához használjuk az Advanced Options (Különleges beál- 
lítások) alatt található csúszkát, illetve a Speed (Sebesség) 
gombot. A Reverse (Visszafelé) paranccsal a végéről indulva 
is lejátszhatjuk a filmet, egészen a kezdő pontig. A sebesség 
módosítása és a visszafelé lejátszás az átmenetekkel és 

a szűrőkkel együtt is használható. 


Címek, feliratok készítése 

Ha szöveget szeretnénk egy-egy epizódhoz hozzáadni, 

a dotitler lehet segítségünkre. Példaként készítsünk egy 
egyszerű albumot, amely a filmünkben játszó karaktereket 
ismerteti. Megfelelő képszerkesztő, például a GIMP segít- 
ségével az albumba akár fényképeket is illeszthetünk. 
Először készítsünk képeket az egyes személyekről, majd 
méretezzük át ezeket. PAL szabványnál a képméret 

720 x576, NTSC-nél pedig 720 x 480 képpont. 

Példánkban feltételezzük, hogy az első személyt öt má- 
sodpercig akarjuk mutatni, ezután négy másodpercet 
hagyunk a váltásra, majd újabb öt másodpercet hagyunk 

a következő színészre is. 

Az FX merüből válasszuk a Create (Létrehozás) parancsot; 
(5-H4)sec"25—225 képkockára lesz szükségünk. A képkoc- 

kák számát párosan tartjuk, ezért a Create From File (Létreho- 
zás fájlból) paranccsal 226 képkockát illesztünk be, amint az 

a 8. ábrán is látható. Ebben a lépésben egyben a , Denys 
Tonkonog" címet is megadjuk. Ez két középre rendezett sor- 
ból áll, és kezdetben a képkocka jobb felső részében helyezke- 
dik el. Mivel végső helyzete szintén ez, a felirat a képkocká- 
kon belül nem mozog. Az X és az Y eltolás (offtset) abban se- 
gít, hogy a teljes címet a képkockákon belül tartsuk, még ak- 
kor is, ha a filmet tévékészüléken vetítik majd, amelynek kép- 
mérete korlátozott lehet. A cím előnézete a 9. ábrán látható. 
Ugyanezzel a módszerrel készítünk egy , Olexiy 
Iykhomyrov" címet is. Ezután visszalépünk szerkesztés 
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8. ábra A ffájlból létrehozott képkockák előnézete 


módba, majd a hatás beillesztéséhez a megfelelő helyeken 
szétvágjuk a filmet. Nem két címjelenetet készítünk, hanem 
négyet, ezek hossza öt, négy, négy majd újra öt másodperc. 
A két középső - négy másodperces - jelenetet az Image 
Luma (Világosság) hatással egyesítjük. 

FX módban kattintsunk a második jelenetre a forgató- 
könyvben. A videóátmenetek közül válasszuk az Image 
Luma hatást. Következő lépésként a , világosság" (luma) ké- 
pet kell megadnunk. Példánkban (10. ábra) egy normál, bal- 
ról jobbra átmenetet tartalmazó fájlt választottunk 

(left to right.png). A módot ne feledjük beillesztésről felül- 
írásra változtatni. Ha végeztünk a leképezéssel, négy he- 
lyett három jelenetünk lesz. A 3. ábrán az egymást váltó cí- 
mek idővonala látható. A világosságot különféle fájlokkal 
használva sok érdekes képi hatást állíthatunk elő. 


Hang 

A Kino segítségével teljesen átalakíthatjuk a jelenetekhez 
tartozó hangot, hangokat adhatunk hozzájuk, zenét kever- 
hetünk alájuk, de természetesen akár érintetlenül is hagy- 
hatjuk őket. Az alákeverésre vagy hangcserére leginkább 
megfelelő zene megtalálása talán a munka legnehezebb ré- 
sze. Ha nem üzleti célra készítjük a filmet, látogassunk el 

a Creative Commons weboldalra. 

A Kino a hangokat WAV formátumban, nem MP3-ban keze- 
li. Ha MP3 formátumban találtuk meg a filmünkhöz megfe- 
lelő hangot, zenét, akkor először WAV formátumra kell ala- 
kítanunk. Használjuk például a mpg123-at: 

mpg123 -wav pelda.wav pelda.mp3 


Ha élő hangot használunk, akkor jobb, ha kimásoljuk 

a hangsávot a .dv forrásból, a megvágott jelenetekkel 
ugyanis a hangok elvesznek. Hangszerkesztésre az srid-t 
használjuk. Keressük meg a jelenetnek azt a kezdő és záró 
pontját, amelyek közé be szeretnénk illeszteni a hangot, 
majd váltsunk Audio (Hang) módba. Válasszuk ki a szüksé- 
ges beállításokat, ide értve a From (Honnan) és a 10 (Hová) 
beállítást is. (11. ábra) Ne feledjük, hogy a kimeneti fájl ne- 
vét kiterjesztés nélkül kell megadnunk. 

A Split (Vágás) szolgáltatással a hang beillesztése előtt 
egyesítsük az érintett jeleneteket. Ellenőrizzük, hogy a for- 
gatókönyvben kiválasztottuk-e azt a jelenetet, amelyhez 

a hangot csatolni akarjuk. Váltsunk FX módba, majd vá- 
lasszuk az Audio Iransition (Hangátmenet) lapot. A Dub 
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9. ábra Az , Olexiy Tykhomyrov" cím elkészítése 
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10. ábra A címek összefűzésének előnézete 


(Szinkronizálás) paranccsal a fájlban lévő hangot csatolhat- 
juk, a Mix (Keverés) paranccsal pedig keverhetjük azt a je- 
lenet meglévő hangjával. Adjuk hozzá a hangot, majd in- 
dítsuk el az előnézetet. Szükség esetén játszadozzunk el 

a beállításokkal, majd kattintsunk a Render gombra. A leké- 
pezés eltarthat egy ideig. 


A film kimentése 

Miután minden összeállt, már csak az eredmény kimentése 
várat magára. Ugyan számos kimeneti formátum közül vá- 
laszthatunk, ha meg akarjuk őrizni az eredeti minőséget, 
akkor inkább írjuk vissza a filmet szalagra, így a merevle- 
mezhellyel is takarékoskodni tudunk. Válasszuk az Export 
(Kimentés) lapot, majd a menü IEEE1394 elemét. A kimen- 
tés megkezdése előtt hívjuk életre a dv1394 eszközt, és tölt- 
sük be az illesztőprogramot. Először — kameránk típusától 
függően - az alábbi parancsok valamelyikét kell kiadnunk, 
ezzel hozzuk létre a dv1394 eszközt. 


PAL rendszernél a parancs a következő: 
mknod -m 666 /dev/dv1394 c 171 34 


NISC rendszernél pedig az alábbi: 
mknod -m 666 /dev/dv1394 c 171 32 
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Specify the output file without the extension 


File: sound 1] 


Sampling Rate: No Change 
Format: WAV (Internal) 


I Scene Split 
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Time: Frames ís 





b Properties 


Dub 
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12. ábra Az Audio Transition (Hangátmenet) menü 


lovábbra is rootként az alábbi parancsot kiadva töltsük 
be az illesztőprogramot: 
modprobe dv1394 


Ezután normál felhasználóként válasszuk a Kino 
Preferences- 2 1EEE1394 (Beállítások- :IEEE1394) parancsát. 
A 13. ábrán láthatóhoz hasonló ablak jelenik meg. Ha a rög- 
zítést a Kino-val végeztük, akkor a DV Capture (DV rögzítés) 
részben a megfelelő adatok jelennek meg. A program mint 
VCR (AV/OC) eszközt ismeri fel a kamerát. A kamerának be- 
kapcsolva kell lennie, és értenie kell a vezérlőjeleket. (Ehhez 
általában lejátszás módban kell lennie.) 

Mivel az IEEE1394 felületen akarjuk kiküldeni a kimenetet, 
válasszuk ki a /dev/dv1394 eszközt. Az OK gombra kattintva 
zárjuk be a beállító menüt. Kattintsunk az Export (Kimen- 
tés) elemre, majd válasszuk az IEEE1394-et. Amit látunk, 

a 14. ábra tartalmához fog hasonlítani. 

Vegyük észre a 14. ábra alján látható információs sort. 

A Kino itt jelzi a dv1394 eszköz elérhetőségét. Ha hibát je- 
lez, várjunk 20-40 másodpercet. Ha a hiba ezután is fennáll, 
akkor a Linux1394 honlapon olvassunk utána az eszköz 
működésének. 

Következő lépésünk a Preview (Előnézet) kiválasztása. 


a at 


A filmnek meg kell jelennie a kamera kijelzőjén. Most állít- 
suk a kamerában lévő szalagot arra a pozícióra, amelytől 

a felvételt el szeretnénk indítani, majd a szalagra írás elindí- 
tásához kattintsunk az Export gombra. Kézikönyve alapján 
ellenőrizzük a kamera jelzéseit. Valószínűleg valami olyat ír 
ki, hogy ,DV Input" (DV bemenet), és lehet, hogy további 
adatokat is megjelenít. 

Ha minden rendben van, állítsuk le a kamerát, tekerjük 


pontosan a kívánt helyre a szalagot, majd kezdjük meg 
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13. ábra A Kino beállítása a film kimentésére, IEEE1394 felületen 
keresztül, kamerára 


TA Elie Edt Miew Help 


Every; fű d frame of: All s 
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b Properties! 


j xporting frame 10506. Time used: 7:05, estimated: 46:18, left: 39:13 





14. ábra A film visszaírása a kamerára 


a kimentést. A szükséges idő hossza pontosan megegyezik 
a film játékidejével. Kimentés közben a Kino az ablak aljára 
írja ki az eltelt és a hátralévő időt. 

A filmet fájlként vagy fájlok csoportjaként is elmenthetjük. 

Más programokkal kiegészítve a Kino a következő célokra 

használható még: 

e  DV fájl előállítása, amely a filmet új formátumban tartal- 
mazza, és amely a Kino közreműködése nélkül további 
tömörítésre vagy kimentésre használható 

e Stills (Állóképek) — A film képkockáinak kimentése 
JPEG formátumú fájlok sorozataként 

e . MPEG - A film MPEG vagy DivX formátumba kódolása 

e . Audio (Hang) - A hangsáv kimentése 

e . DV pipe (DV csővezeték) -— Elegáns eszköz saját módsze- 
rek létrehozására a filmek kimentésére. Olyan alapszol- 
gáltatásokat is támogat, mint a kimentés MPEG1 (video 
CD készítéséhez) vagy MPEG2 formátumba. 


Ne feledjük, a kimentési szolgáltatások nem működnek a gé- 
pünkön, amíg a szükséges programokat nem telepítettük. 

A DV fájlba való kiírás az IEEE1394 felületen keresztül, kame- 
rára való kimentéshez nagyon hasonló módon működik. 

Ha a filmet egyetlen .dv fájlba szeretnénk kiírni, válasszuk 
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15. ábra Film kimentése .dv fáljba 


az Export/DV File parancsot. Tiltsuk le az Auto Spilt Files 
(Önműködő vágás) szolgáltatást, majd az Export Range (Ki- 
mentési tartomány) beállításhoz válasszuk az All (Minden) 
értéket, ezzel a jelenetlista összes tagját ki tudjuk írni. 

A Type File (Fájltípus) beállításnál a Raw DV (Nyers DV) ér- 
téket válasszuk. A Frame per File (Képkockalfáj]) és a Max 
File name (Max. fájlnév) mezőbe írjunk nullát, ahogy az 

a 15. ábrán is látható. Kattintsunk az Export gombra. A Kino 
megkezdi a kiírást, miközben jelzi a folyamat befejezéséig 
hátralévő időt. 


Záró megjegyzések 

A Kino jelenleg is fejlesztés alatt áll, ezért ne lepődjünk 
meg, ha a szerkesztés vagy a metszés használata közben 
időnként összeomlik. Ügyeljünk filmünk rendszeres menté- 
sére. Bár a Kino figyelemmel követi az általa létrehozott fáj- 
lokat, összeomlás esetén elveszítheti a fonalat. Merevleme- 
zünk tisztán tartása érdekében ne felejtsük el törölni a feles- 
leges .dv fájlokat. 


Köszönetnyilvánítás 

A szerzők szeretnék hálájukat kifejezni Paul Bartholdi pro- 
fesszornak, az olaszországi Nemzetközi Elméleti Fizikai Köz- 
pont Genfi Obszervatórium munkatársának, amiért valódi 
internetkapcsolatot biztosított nekik, ami a Dnepropetrovski 
Nemzeti Egyetemről elérhetetlen lett volna. 


Linux Journal 2004. december, 128. szám 


Olexiy Tykhomyrov (tigeraTff.dsu.dp.ua) 1994 óta 
használja a Linuxot. A Dnepropetrovski Nemzeti 
Egyetem Kísérleti Fizika tanszékén dolgozik, fizI- 
kát és kommunikációt oktat. Imádja Misha nevű 
fiát, aki Tigrisnek hívja őt, amiért a diákjainak 
egy része fél tőle. Tigris imád úszni és utazni. 


Denis Tonkonog, Tigris korábbi hallgatója, szin- 
tén a Dnepropetrovski Nemzeti Egyetem mun- 
katársa. Kedvenc időtöltése az utazás és 

a fegyveres horgászás. Barátai Fekete Macská- 
nak hívják, de senki nem árulja el, miért. 

A deniseff.dsu.dp.ua címen érhető el. 





Bővitsuk a GIIMP-et 


Miután megismerkedtünk a GIMP legfontosabb képességeivel, a használat során 
bizonyára felmerült bennünk a kérdés: tud-e ennél többet a program, vagy lehet-e 
valamilyen módszerrel a gyakran ismétlődő műveletek végrehajtását felgyorsítani. 
Természetesen a készítők már a kezdet kezdetén gondoltak erre a lehetőségre, 


így a válasz mindkét kérdésre igen! 


GIMP kétféle megoldást is kínál a bővítésre, 
AA mindkettőt egy-egy programnyelven keresztül. 

A korábbi változatokban a scheme programozási 
nyelvet használhatjuk, amelynek azonban kissé nehezen 
érthető a szintaxisa. A következő oldalakon az egyszerűbb 
megoldással fogunk foglalkozni, mégpedig a Python prog- 
ramnyelven készített beépülő modulok készítésével. 

A modulok elkészítéséhez azért is célszerű a Python nyelvet 
választani, mert véleményem szerint ez az egyik leg- 
könnyebben elsajátítható nyelv, mely egyszerűsége ellenére 
is alkalmas összetett programok elkészítésére. A nyelv 
egyik nagy előnye az is, hogy könnyedén illeszthető más 
programkönyvtárakhoz, így napjainkban már használha- 
tunk például GIKt vagy Ot alapú grafikus felületet is 

a Python programjainkban. 

Az alábbiakban a nyelv alapelemeit szeretném bemutatni, 
mindössze olyan mélységben, amennyire a GIMP modulok 
készítéséhez szükségünk lesz rá. 

Minden programnyelvben találhatunk programvezérlési 
szerkezeteket, mint amilyenek a ciklusok és a feltétel vizsgá- 
latra szolgáló utasítások. A Python-ban egy számláló ciklus 
az 1. listán látható módon készíthető el. Szintén az 1. listán 
látható az elöl tesztelő ciklus és a feltételvizsgálat formailag 
helyes megadása is. Ha jól megfigyeljük a listát azonnal lát- 
ható a formátum egyszerűsége. A ciklus vagy vizsgálat kez- 
detét a : karakter jelzi, majd az utasítások következnek. 

Az utasítások beírásánál figyelni kell arra, hogy a Python ér- 
telmező a tabulátorok vagy szóközök alapján határozza meg 
az utasításblokk végét. lehát a második listán látható utasí- 
tások mindegyike helytelen, mert nem kezdtük beljebb az 
utasításblokkba tartozó sorokat. Aki írt már egyszerűbb vagy 
összetettebb programokat, annak nem lesz nehéz megszok- 
nia a Python formai követelményeit sem, hiszen már az átte- 
kinthetőség kedvéért sem írjuk folyamatosan, mindenféle 
tagolás nélkül a sorokat egymás alá. 

A Pythonban természetesen lehetőségünk van a korszerű 
programozási nyelvekben megszokott függvények és osztá- 
lyok használatára is. A 3. listán látható egy függvény, mely 
megfelel a nyelv formai követelményeinek. A függvényünk 
nem csinál mást, csupán kiírja az első paraméter értékét, majd 
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az első és a második paraméter összegét. A Pythonban nem 
szükséges sokat foglalkozunk a változók típusával, elegendő 
csak arra figyelni, hogy azonos típusú változókkal végezzünk 
műveleteket. Alapvetően három típussal dolgozhatunk. 
Számokkal, szövegekkel és listákkal. Természetesen nem 
adhatunk össze egy számot egy szöveggel és listával sem. 


1. lista 


f számláló ciklus 
for a in range(1,10): 
utasítások 


ft elöl tesztelő ciklus 
0 
while 11-10: 

1-1 ri 


f feltételvizsgálat 
1f FELTÉTEL: 
utasítások 
else: 
utasítások 


2. lista 


ft számláló ciklus helytelen 
for a in range(i1,10) : 
print a 


ft elöl tesztelő ciklus helytelen 
1-0 

while 1: 

print 1 

Ten 0 

break 
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3. lista 


ft Függvény megadása 

def fuggvenyneve(parameteri, parameter2): 
utasításblokk 
print parameteri1 
print parameteri1 4 parameter2 


4. lista 
$1!/usr/bin/env python 
from gimpfu import " 


f A fo fuggveny, ami a munkat vegzi 
def anigifCimage, drawable, neww, newh, 
filename) : 
newimage - pdb.gimp file load(filename, 
s f1lename) 
newlayer - newimage.active layer 
newlayer.scale(neww, newh, 0) 
pdb.gimp. selection all (newimage) 
pdb.gimp. edit copy(newimage.active layer) 
mylayer - gimp.Layer( 
3 image, "from 
s neww, newh, 
3 1mage.base type, 100, NORMAL MODE) 
1mage.add layer(mylayer, 0) 
mylayer.set offsets((image.width-neww) / 2, 
ss (1mage.height-newh) / 2) 
image.active layer - mylayer 
pdb.gimp. edit paste(mylayer, 1) 
pdb.gimp. floating sel anchor( 
1mage.floating selection 


3 filename, 


f Modul bejegyzese 
register( 
-"python fu anigif" , 
"Animated GIF creator", 
"Create animated GIF image from single 
s images" , 
"zoltan Fabian", 
"zoltan Fabian", 
"2004" , 
" Images/Python-Fu/Gi fAnim" , 
"RGB/" , 
L 
( PFLINT, "neww7, "New width", 100), 
( PF.INT, "newh7", "New height", 100), 
( PF FILE, "filename", "Filename7, "") 


[1], anigif) 


main0O 
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5. lista 


register ( modul neve, "modul leírása", 
s "modul bővebb leírása", 


s "készítő neve", "copyright információk" , 
sz "dátum" , 
sz "modul helye a menüben", "KÉPTÍPUSOK" , 


5 paraméterek[], visszatérési értékekt[], 
sa modul fő függvénye 
9 


Mindössze ennyi elegendő a modulok készítésének megér- 
téséhez, tehát a most egy példán keresztül bemutatom ked- 
ves olvasóimnak, hogyan is lenne célszerű elkészíteni egy 
GIMP kiegészítő modult. A 4. listán látható a példa, igye- 
keztem minél rövidebben használható rutint írni, de termé- 
szetesen a továbbiakban bővíteni is fogjuk a programunkat. 
A GIMP alapértelmezésben a megadott könyvtárakban ke- 
resi a kiegészítő modulokat, tehát a beállítások párbeszéd- 
ablakában meg kell határoznunk a modulokat tartalmazó 
könyvtárakat. Amennyiben ezt a lépést kihagyjuk, a prog- 
ram a felhasználó saját könyvtárában lévő .gimp-2.0/plug- 
ins könyvtárban vizsgálja az állományokat. A Python nyel- 
ven készült modulok írásakor két fontos dolgot kell megje- 
gyeznünk. Az egyik, hogy a from gimpfu import " sornak 
szerepelnie kell a modul forrásában, mert így használhatjuk 
a GIMP beépített lehetőségeit. A másik fontos dolog pedig, 
a register függvény meghívása a megfelelő paraméterek- 
kel. A függvény paraméterezése az 5. listán olvasható. 

A paraméterek közül bővebb magyarázatra szolgál a modul 
helyét meghatározó "modul helye a menüben" paraméter. 
Ez a paraméter határozza meg, hogy a GIMP-ben milyen 
menüpontokon keresztül találjuk meg a kiegészítő modult. 
A megfelelő formátum az alábbi példákból jól látható: 


" Images/Python-Fu/AnimG1f" 


vagy 
" -Toolboxzs/XxXtns/Python-Fu/AnimG1f" 


A GIMP indulásakor alapértelmezésben nincs megnyitva 
semmilyen kép, tehát amennyiben a GIMP eszköztárának 
menüpontjai között szeretnénk találkozni az elkészített 
modullal, akkor a második megoldás szerint a az eszköztár- 
ban az Xtns menüben a Python-Hu pontot választva talál- 
hatjuk meg az AnimGif modult, melynek forrásával a 4-es 
listán ismerkedhettünk meg. A másik fontos paramétere 

a register függvénynek, a KÉPTÍPUSOK nevet viseli. Ezzel 
a paraméterrel határozhatjuk meg, hogy a GIMP milyen 
képekre engedélyezze a modul használatát. A típus lehet 
"RGB", GRAY" vagy INDEXED" de természetesen a " ka- 
rakter helyett használhatjuk a pontos értéket is, mely meg- 
határozza az elfogadható színmélységet. Például, amennyi- 
ben csak 24-bites képekre használható a modul, akkor 

a megfelelő érték az RGB24 lesz. Több értéket megadhatunk 
a karakterláncban, vesszővel elválasztva. 

Moduljaink készítése során előfordulhat, hogy a modul- 
nak paramétereket szeretnénk átadni a GIMP-ből. Meg 
kell jegyezni, hogy minden modul fő függvényének első 


6. lista 


PF INT 

PF FLOAT 

PF STRING 

PF INTARRAY 
PF FLOATARRAY 
PF STRINGARRAY 
PF COLOR 

PF REGION 

PF. IMAGE 

PF LAYER 

PF. CHANNEL 

PF TOGGLE 

PF. BOOL 

PF FONT 

le BB 

PF. BRUSH 

PF PATTERN 

PF GRADIENT 


két paraméterében a GIMP átadja az éppen aktuális raj- 
zolásra használt felületet és az aktuális képet, tehát a fő 
függvénynek legalább két paraméterrel kell rendelkeznie 
a definícióban is. E két alapértelmezett paraméteren kívül 
a paraméterek[] paraméterben adhatunk meg továbbia- 
kat. Ahogyan a 4. listán is látható, a szögletes zárójelben 
(python lista) vesszővel elválasztva felsoroljuk a szükséges 
paramétereket. A paraméterekről is háromféle információt 
szükséges a GIMP tudtára adni, mégpedig a paraméter tí- 
pusát, a párbeszédablakban megjelenő szöveget és a para- 
méter alapértelmezett értékét. A leggyakoribb paraméte- 
rek típusa a 6. listán olvasható. A négyes listán látható 
példában könnyen nyomon követhető a paraméterek 
meghatározásának módja. 

Végül a modul használatba vételéhez a regisztráció el- 
végzése után meg kell hívni a mainŐ) függvényt, mely 

a GIMP beépített modulkezelő függvénye, tehát semmi 
más tennivalónk nincs a modul működtetéséhez. 

lehát amikor a GIMP elindul, végignézi az elérési utakat 
ahol modulokat és egyéb kiegészítőket tárolhatunk, majd 
a saját készítésű moduljainkat megtalálva meghívja az 
abban található register függvényt. Ezzel készen is 

van a modul alaphelyzetbe állítása és a megadott néven, 
a megfelelő menüpontokon keresztül megtalálhatjuk 

a GIMP menüjében. 

A programozási alapismeretek elsajátítása után, térjünk rá 
első modulunk tárgyalására. A modul célja, hogy az animált 
GIF képek elkészítését megkönnyítsük. A kiegészítő modu- 
lok használata nélkül minden képet, melyet a végeredmé- 
nyen látni szeretnénk, meg kellene nyitnunk, majd az át- 
méretezés után mindent kijelölni és a vágólapra helyezni. 
A másolás után átváltunk az készülő képre, majd ott beil- 
lesztjük a másolt képrészletet és új rétegként létrehozzuk 

a következő képkockát. Ez a folyamat ugyan csak néhány 
billentyűlenyomást igényel, kis gyakorlással már észre sem 
vesszük az mozdulatokat, de mégis célszerűnek tartom egy 
modulba foglalni az ismétlődő műveleteket. 


www.linuxvilag.hu 





lekintsük át a 4. listán látható programot. A program elején 
látható, hogy a forrást a Python értelmező fogja végrehajta- 
ni és az is, hogy a GIMP modulkiegészítőit is használni sze- 
retnénk. A következő fontos dolog, maga a műveleteket 
végrehajtó függvény. Az anigif függvény a GIMP-től meg- 
kapja az aktuális rajzterületet és a képet, majd a register 
eljárás meghívásakor bejegyzett egyéb változókat. 

Első lépésként betölti a fi lename paraméterben kapott ké- 
pet, mégpedig a GIMP beépített függvényének segítségé- 
vel. A betöltés után a képről megállapítja az aktív réteget 
(ez maga a kép lesz, amennyiben nem Photoshop vagy 
GIMP formátumú képet töltünk be) és azt átméretezi a kí- 
vánt méretre. A szükséges méreteket szintén a modul indu- 
lásakor megjelenő párbeszédablakban állítjuk be, majd 

a new és newh paramétereken keresztül a fő függvényben 
használhatjuk. Az átméretezés után szintén a GIMP beépí- 
tett függvényadatbázisából választjuk ki a megfelelő függ- 
vényt, melynek segítségével az aktív réteget teljes egészé- 
ben kijelöljük és a vágólapra másoljuk. 

A következő lépés célszerűen az lenne, hogy a célképen 

a beillesztendő képnek létrehozunk egy új réteget. A GIMP 
minden működése elérhető a Python felületen keresztül is, 
így létrehozhatunk új réteget is a gimp . Layer objektum lét- 
rehozásával. Az objektum létrehozásához hét paraméterre 
van szükség, melyek sorrendben a következők: első a kép, 
melyhez a réteg tartozik. A második a réteg neve, amely 
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2. kép A modul használat közben 


majd a GIMP réteg-kezelőjében is megjelenik. A harma- 
dik és a negyedik határozza meg a kép méretét, míg az 
ötödik a réteg típusát. A réteg típusa lehet RGB IMAGE, 
RGBA IMAGE, GRAY IMAGE, GRAYA IMAGE, INDEXED IMAGE 
vagy INDEXEDA IMAGE. A hatodik paraméter a réteg átlát- 
szatlanságának mértékét határozzuk meg. 100-as értéknél 
a réteg egyáltalán nem lesz átlátszó, míg nulla értéknél 
teljesen átlátszó réteget kapunk. A hetedik paraméter 
pedig a réteg kirajzolási módját adja meg, amit most 
NORMAL MODE-ként határozunk meg, tehát a réteggel 
semmilyen műveletet nem kell végezni a kirajzoláskor. 

Az 1. táblázatban egy rövid összefoglaló található 

a gimp . Layer objektum változóiról és metódusairól. 

Az új réteg létrehozása után már csak annyi dolgunk 
maradt, hogy azt a képhez hozzáadjuk és beállítjuk a meg- 
felelő eltolást és átméretezést, hogy az cél-kép közepére 
kerüljön a beillesztett kép. A beillesztéshez ismét a GIMP 
egyik menüpontjához tartozó eljárását hívjuk meg, mégpe- 
dig apdb.gimp. edit paste metódust. Itt látható, hogy 
minden beépülő modul vagy elérhető függvény használ- 
ható a PDB (Plug-in DataBase) adatbázison keresztül, 
tehát itt is érvényes a bővíthetőség és az újra felhasználha- 
tóság elve. A réteg beillesztése után a fő függvényünkben 
az utolsó feladat már csak a kijelölés megszüntetése, vagyis 
a beillesztett tartalom rögzítése. 

A modul további sorai tartalmazzák a GIMP adatbázisába 
történő felvételt (a register függvény segítségével) és 

a modul elindítását. 

Végül az egyes rétegek beillesztése után még egy egyszerű 
feladatot kell megoldanunk, hogy az animált GIF kép ne 
tartalmazzon üres képkockát. A két legalsó réteget egyesíte- 
ni kell a réteg-kezelőben a Merge Down menüpont kiválasz- 
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tásával. Mindezek után máris menthetjük GIF formátumba 
az elkészült képet. A GIMP érdeklődni fog a mentés formá- 
tuma iránt, itt válasszuk ki az animált GIF lehetőséget és 
készen is vagyunk első modulunk tesztelésével. Az 1-es 
képen látható a modul beállító párbeszédablaka, amelynek 
felületét a register eljárás meghívásakor hozzuk létre. 

A 2-es képen a modul segítségével beillesztett rétegekből álló 
kép részletei tekinthetők meg. 

Amint látható, nem túl bonyolult dolog egy GIMP modult 
elkészíteni, köszönhetően annak, hogy a Python nyelv tá- 
mogatása is belekerült a GIMP nyelvezetébe. Felmerülhet 
azonban az a kérdés kedves olvasóimban, hogy honnan 
tudhatjuk meg, milyen lehetőségek rejlenek a háttérben, 
milyen feladatokat végezhetünk el egy-egy rövid program- 
sor segítségével. 

Mivel a GIMP tartalmaz egy modul- és függvényböngésző 
párbeszédablakot, így könnyedén utána járhatunk a meglé- 
vő modulok képességeinek. 

A GIMP fő ablakában található az Xtns -5 Python-FU -: 
PDB Browser menüpont, melynek segítségével minden be- 
épülő modulról vagy függvényről bővebb információkhoz 
juthatunk. Amint megnyitjuk ezt a párbeszédablakot, a ren- 
delkezésre álló függvények listáját láthatjuk és kedvünkre 
válogathatunk közöttük. Egy függvényt kiválasztva az ab- 
lak jobb oldali részén annak rövid leírását, paramétereit és 
használatát segítő szöveges leírását olvashatjuk. Az ablak- 
ban lehetőségünk van a függvények közötti keresésre is, 
tehát igazán néhány óra olvasgatással hamarosan otthon 
érezhetjük magunkat a GIMP moduljainak körében. 

A másik lehetőség az ismeretek bővítésére szintén a fő esz- 
köztár menüjén keresztül érhető el. Az Xtns -53 Python-Eu -: 
Console menüpontok kiválasztásával megjelenik egy szö- 
vegbevitelre alkalmas párbeszédablak, ahol írhatunk külön- 
féle Python nyelven értelmezhető parancsokat, melyeknek 
kimenete az ablak felső részét elfoglaló mezőben azonnal 
láthatóvá válik. Első lépésben mindig töltsük be a gimpfu 
modult, hogy a GIMP saját függvényei is elérhetővé válja- 
nak. Ezt az import gimpfu utasítás begépelésével érhet- 

jük el, ahogyan a modul írásakor is tettük. Ezután már 

a Python nyelvben használatos dir függvény alkalmazásá- 
val minden objektumról megjeleníthetjük a metódusokat 
és az objektum változóit. Bővebb leíráshoz juthatunk, ha 

a import pydoc utasítással a dokumentációt segítő modult is 
betöltjük majd a pydoc. doc(VALAMI) függvény használatá- 
val kérünk segítséget a kérdéses objektumról. A konzol 
azonban nem csak ismerkedésre alkalmas, hiszen segítségé- 
vel a modulokat még a tényleges elkészítés előtt részletei- 
ben is ellenőrizhetjük, továbbá kipróbálhatjuk a meglévő 
függvényeinket is. 

Meg kell jegyeznem, hogy amikor a GIMP-et kiegészítjük 
valamilyen modullal, a regisztráció után más modulokban 
is használhatjuk a saját függvényeinket, tehát megtalálhat- 
juk a PDB Browser listájában is. 

A következő részben folytathatjuk az ismerkedést bonyolul- 
tabb feladatok megoldásával, addig is bizonyára az érdeklő- 
dő olvasók sikerrel veszik a kezdeti nehézségeket. 

Addig is mindenkinek kellemes ünnepeket és Boldog 

Új Évet kíván a szerző. 


Fábián Zoltán 


A felhasználói viselkedés vizsgálata (3. rész) 


A sorozat előző részében megvizsgáltuk az adatgyűjtési módszereket. Most már 
ideje használni Is ezeket, hogy a legyen mit elemeznie a Nagy Testvérnek. 


A legjobb megoldás 

A legfrissebb adatok alapján az internet legelterjedtebb 
webkiszolgálója az Apache, a maga közel 6790-os részesedé- 
sével. Éppen ezért döntöttem úgy, hogy a modellezést en- 
nek a programnak az eseménynaplói alapján fogom bemu- 
tatni. A választást az is megerősíti, hogy a témával kapcso- 
latban a Google közel 160 olyan szoftvert talált, amelyek 

az eseménynapló valamiféle feldolgozásával, statisztikák 
készítésével és modellezéssel foglalkozik. 

Az Apache előnye, hogy teljesen nyílt forrású, rengeteg 
platformon és operációs rendszeren fut (Unix, Linux, BSD, 
Microsoft Windows, Novell Netware), széleskörűen támoga- 
tott, és rengeteg kiegészítő modul érhető el hozzá. Beállítá- 
sa egyszerű, egészen szélsőséges terhelési viszonyok között 
is használható, kiegészítő modul használatával pedig akár 
elosztottan is futtatható. Az internetes közösség folyamato- 
san jelentkezik újabb és újabb modulokkal. (Van például 
adatbázisba naplózó modul is.) 


Apache naplózás 

Az Apache naplózó modulja a mod log config 

(2 http://httpd.apache.org/docs/mod/mod log config.html), 
amely alapból feltelepül minden fent említett rendszeren. 
Az eseménynaplóba kerülő bejegyzések részletessége igen 
változatos lehet, a modellezés leghatékonyabb támogatásá- 
hoz azonban érdemes a legrészletesebben naplózni. 

Az Apache webszerveren a LogFormat direktíva segítségével 
adható meg, hogy milyen adatok és milyen sorrendben ke- 
rüljenek az eseménynapló egy bejegyzésébe. A lehetséges 
direktíva értékek: 


e Ja: az ügyfél IP címe, 

e 74: a kiszolgáló (helyi) IP cím, 

e Jób: az elküldött adat nagysága 
(Common Log Format formátum), 

e  96c: a kapcsolat státusza a kérés teljesítése után, 

e 7: a lekért erőforrás (fájl) neve a helyi 
fájlrendszeren, 

e  96h: az ügyfél neve, 

e  96H: a kérés protokollja, 

e 961: a távoli eseménynapló neve 
(általában üres), 

e  9m:. a kérés metódusa, 
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e 969: a lekérdezést tartalmazó karakterlánc (guery string), 
kiegészítve egy kérdőjellel ha létezik, egyébként üres, 
(például: ?action-register§step-3€5ess-12345678) 

e Jr: a kérés első sora, például: 

"GET /modul.php?action-register 
— 8S5tep—3£5ess-12345678 HTTP/1.0", 

e Jós: a kérés kiszolgálásának státusza 
(HTIP protokoll státusz kód), 

e Jt: időbélyeg (Common Log Format), 

e  96T: a kérés kiszolgálására fordított idő, másodpercben, 

e 76: távoli felhasználó (azonosításból származik), 

e 904: a kért URI a guery string nélkül, például: 

"/modul .php", 
e  Jóv: a kiszolgáló szerver neve. 


Amint azt már a sorozat korábbi részeiben említettem a fen- 
ti adatok alapján nem lehet egyértelműen elkülöníteni az 
egyes felhasználókat, főleg ha azok azonos proxy vagy tűz- 
fal mögül látogatják az elemezni kívánt portált. 

A modul lehetőséget nyújt az ügyfél felől érkező kérések- 
ben található változók értékének eseménynaplóba írására 
is. Ennek segítségével tudjuk naplózni az ügyfél böngésző- 
jének típusát és a , előző oldal" vagy küldő oldal (referer) ér- 
tékét is. Ehhez a következő direktívákat kell használnunk: 


e  JíReferer3: a referer értéke, 
e 96(User-Agent3: a böngésző típusa. 


A direktíva-értékek tetszőlegesen kombinálhatóak. 
Íme néhány példa: 


e Általános: "Xh X1 Yu 4t VATrNV" Xss Xb" 
Példa: 
217.20.135.85 - - [08/Apr/2004:18:06:47 --0200] 


sz EGET / HTTP/1.07 200 16897 


e Összetett: "X4h 961 Xu 9t VÉrNV" s Xb 
se RefererjiV" WV 9etvser-agentjivV", 


Példa: 


62.165.209.144 - - [08/Apr/2004:18:30:55 --0200] 
ss EGET / HTTP/1.17" 200 16937 
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"http: //ww. oktaton.hu/index . php?inc-portal" 
sz "Mozil]a/4.0 (compatible; MSIE 6.0; Windows 
NT 5.1)" 


e Egyedi: "76h 961 2u 2t Vr" 76s 96b 
sz getRefererji WV" V96tUser-AgentjiV" 
sz. cookiejni" 2T 9v VXUV Xxc BT, 


Példa: 

42.165.229.144 - - [08/Apr/2004:18:30:55 --0200] 

sz GET / HTTP/1.17 200 16937 "http://ww. oktaton. hu/ 
551 ndex.php?inc-portal" "Mozil1]a/4.0 (compatible; 
S$MSIE 6.0; Windows NT 5.1)" 

s "42.165.229.144.388110814418554597 0 

sz ww.jegyzet.com 7/7 - 

sz /srv/ww/ww . jegyzet . com/index . php 


Látható, hogy a felhasználói viselkedés modellezésének 
pontossága jelentősen növelhető a referer és a böngésző 
típusára vonatkozó adatok felhasználásával. Az egyes 
weblapok (különböző tartalom szerinti) elválasztását a 76gd és 
JU direktívák értékének felhasználása könnyíti meg, ugyan- 
is azonos 3U értékek esetén a 96g értékek különbözősége 
más-más weboldalt jelent. Ugyanakkor elmondható, hogy 
az általánosan használt eseménynapló bejegyzés formátu- 
mok a modellezés szempontjából felesleges adatokat is tar- 
talmaznak (például: elküldött adat mérete, távoli esemény- 
napló neve), azonban az általánosan szokásos biztonsági 
naplózás miatt ezeket általában nem szokás eltávolítani. 

A legjelentősebb probléma a fenti eseménynapló szerke- 
zetekkel, hogy nem tartalmaznak a felhasználókat egyér- 
telműen megkülönböztető bejegyzéseket: a 9u paramé- 
ter értéke általában üres, mert a felhasználói azonosítást 

a legtöbb helyen nem a webszerver végzi, hanem a por- 
tál alkalmazása. Gyakori, hogy egyes erőforrásokat a web- 
szerver által biztosított hitelesítési mechanizmussal (is) vé- 
denek, jellemző azonban, hogy az egyes felhasználók 
ugyanazt a felhasználónév és jelszó párost használják, az- 
az az így keletkező adat nem használható a felhasználók 
megkülönböztetésére. 


Egyedi felhasználói azonosító 

Szerencsére van megoldás, ugyanis az Apache webszer- 
verhez létezik egy modul, amely segítségével minden 
egyes felhasználóhoz egyedi azonosító rendelhető. 

Ez a mod usertrack modul (3 http://httpd.apache.org/ 
docs/mod/mod usertrack.html). 

A modul segítségével minden felhasználóhoz egy munka- 
menet azonosító rendelhető, függetlenül a kiszolgált, futta- 
tott portál szofítverétől. 

A modul működése igen egyszerű: a webszerver minden 
kérés esetén megkapja a HITP fejlécekben a korábban az 
adott weboldalra juttatott sütiket. A modul megvizsgálja, 
hogy létezik-e a munkamenet azonosító süti, és ha úgy 
találja, hogy az létezik, és még ráadásul érvényes is, akkor 
egyszerűen visszajuttatja a klienshez. A visszaküldést 

a webkiszolgáló automatikusan végzi a HIIP fejlécben, 

a süti kezelés módszereinek megfelelően. 

Amennyiben nem talál munkamenet azonosító sütit, akkor 
a modul automatikusan generál egyet. Minden munkame- 
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1. ábra A kérések idő alapú elkülönítésének algoritmusa 


net azonosítónak egyedinek kell lennie, ami egy nagy 

(sok ezer lekérés percenként) forgalmú portál esetén nem 
olyan triviális feladat, mert a szoftveres véletlenszám gene- 
rátorok hajlamosak ismételni (szekvenciába esni). A modul 
az egyedi munkamenet azonosítót a következőképpen 
konstruálja meg: 


e — prefix karakterlánc (tetszés szerint beállítható), 

e az ügyfél IP címe, vagy a helyi gép (host) neve, 

e a kérést kiszolgáló folyamat (process) azonosítója, 
e a kérés időbélyege másodperc pontossággal, 

e a kérés időbélyege mikromásodperc pontossággal. 


A modul a fenti adatokat összefűzi, és az így előálló karak- 
terlánc lesz az egyedi munkamenet azonosító. 

A modul megbízhatósága általában véve a szerver oldali 
adatgyűjtésnél ismertetett problémák miatt nem 10095-os. 
A kliens oldalon a sütik elfogadásának letiltásával a fel- 
használó minden egyes letöltésekor új munkamenet azo- 
nosító keletkezik, hiszen a böngésző nem tárolhatja 

a sütiket, azaz nincs hol tárolni az azonosítót. Az újabb 
böngészőkben lehetőség van arra, hogy a munkamenet 
azonosító sütik ne kerüljenek letiltásra. Ezt a modul 

A modul a következő beállításokkal vezérelhető (a beállításo- 
kat az Apache kiszolgáló beállítási fájljában kell elhelyezni): 


e  CookieDomain: a süti érvényessége, egyes böngé- 
sző beállítások esetén a böngésző csak az éppen hasz- 
nált szervertől fogad el sütit, ezért explicit módon 
meg kell adni, hogy melyik tartományhoz (domain) 
tartozik a süti. 

e  CookieExpires: ezzel az értékkel tulajdonképpen 
azt mondjuk meg, hogy mennyi ideig lehet a felhasz- 
náló egy látogatáson belül inaktív (nem kér le újabb 
oldalt a szervertől). Ha letelik a megadott idő, akkor 
a következő oldallekérés esetén a felhasználót új látoga- 
tóként kezeljük. Könnyen elképzelhető, hogy közben 
másvalaki ült le a géphez. 

e CookieName: opcionális, a süti elnevezése. 

e  CookiePrefix: az azonosító elejére kerülő tetszőleges 
karakterlánc, opcionális. 

e  CookieStyle: a létező süti szabványoknak megfele- 
lő típusú süti küldés beállítása (nagyon régi böngé- 
szők használata esetén lehet szükséges a módosítása). 
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e . Cookierracking: mivel a modul betöltése esetén nem 
kerül automatikusan használatra, ezért explicit módon 
kell bekapcsolni. 


Egy tipikus konfigurációs példa: 
CookieDomain ".jegyzet. com" 
CookieExpires "30 minutes" 

Cook1eName "www-Jegyzet-com-user-tracking" 
CookiesStyle "Cookie" 


Cookt1eTracking "on 


A modul beállítási lehetőségei közül a legfontosabb 

a CookieExpi res, mert ennek értéke akár jelentősen is befo- 
lyásolhatja a felhasználói modellezést. A paraméter értékét 
minden esetben az adott portál felhasználási viszonyaihoz 
kell megállapítani figyelembe véve a látogatók áramlását 

és szokásait. 

A modul egyetlen feladata tehát az eseménynapló bejegy- 
zések kiegészítése egy munkamenet azonosítóval, amely 
azonosító a feldolgozás során a felhasználók szétválogatá- 
sát, megkülönböztetését szolgálja. 


Felhasználók elkülönítése 

Ha valamilyen oknál fogva nem tudjuk használni 

a mod usertrack modult, akkor is van lehetőség a felhaszná- 
lók elkülönítésére. 

Ebben az esetben a látogatók elkülönítése és útvonalaik 
összegyűjtése elsődlegesen az ÍP cím, távoli eseménynap- 











ló, távoli telhasználó adatok alapján történik, de az ismer- 
tetett problémák miatt ez önmagában nem elegendő az 
egyértelmű megkülönböztetéshez. lovábbi segítséget 
nyújt a referer és a böngésző adatok jelenléte. Azonban 

a legegyszerűbb szerkezetű eseménynaplók nem tartal- 
maznak az IP címen és a kérés időpontján kívül több 
olyan adatot, amely segítené a látogatók elkülönítését, 
vagy egy nagyvállalati hálózatból érkező látogatók esetén 
jellemzően a böngésző adatok is azonosak. 

Az idő alapú elkülönítés során (1. ábra) az éppen vizsgált 
kérést a megadott időintervallumon belül eső, kéréssel ren- 
delkező látogatóhoz próbáljuk meg csatolni, oly módon, 
hogy a fent említett adatok közül a lehető legtöbb egyez- 
zen. leljes egyezés esetén a vizsgált kérést az adott látoga- 
tóhoz kapcsoljuk, ha nem találtunk teljes egyezést, akkor 
mint új látogató kezeljük, és egy új útvonal tömb bejegy- 
zést nyitunk neki. 


Folytatás 

A sorozat következő részében az elkülönített felhasználóink 
útvonalait fogjuk részletesen kielemezni és elkészítjük az 
átlagos viselkedést bemutató modelleket. 


Beszédes Balázs (beszedesgei.hu) 

24 éves, az e-Médila Informatikánál mérnök- 
informatikus. Hobbija a kerékpározás és 

a kirándulás. 


Értékeld a Linuxvilág 
cikkeit! 


I Mostantól lehetőség van rá, hogy pontszámmal értékeld a Linuxvilágban megjelent cikkeket. Minden 
szám tartalomjegyzékében az adott cikk dobozában megjelölheted, hogy milyen osztályzatot adsz rá 


1-től 5-ig. Emellett a cikkek összesítő oldalán is lehetőség van a cikkek értékelésére. 

Egyszerre több cikket is értékelhetsz: jelöld meg, hogy milyen osztályzatot adsz a cikkeknek és kattints 
az oldal tetején vagy alján található , Pontozás" gombra. 

Ha bővebben kívánod véleményezni a cikket, kérjük írd meg a hozzászólásokban. 

Reméljük sokan fognak élni a lehetőséggel és ezáltal hasznos visszajelzést kapunk arról, hogy mely 
cikkek/témák a legnépszerűbbek. Az osztályzatok alapján hamarosan megjelentetünk egy folyamatosan 
frissülő toplistát is. 


www.linuxvilag.hu 
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FreeBSD - a szomszéd vár (3. rész) 


A FreeBSD alaprendszer és a külső programok telepítése. 


ajdanán bőven megelégedtünk volna programok 
oly bő választékával, amit egy FreeBSD alaprend- 
szer nyújt: programozható parancssor (burok), szö- 


vegszerkesztő programok, fordítóprogramok (GNU C), há- 
lózati munkát segítő programcsomag, s még sok száz kis 
programocska, amelyek megkönnyítik a munkánkat. 
Manapság ezen programok megléte teljesen természetes, 

s egyben az , igazi" munkához kevés. 


Az alaprendszer telepítése 

Ha minden igaz, akkor rendelkezünk egy friss és naprakész 
alaprendszer forrással; sőt, talán még a helyes beállítások is 
már régen megtörténtek. Nincs más teendő, mint lefordíta- 
ni, majd a helyére másolni az új rendszermagot és az új 
alaprendszert. Ez egyszerűnek hangzik, de valójában is egy 
egyszerű művelet. Eleinte azonban bonyolult és összetett 
tevékenységnek gondoljuk, de hónapok alatt rutinná, majd 
,szertartássá" válhat. 

Ha valaha fordítottunk már mások által írt alkalmazásokat, 
akkor nem lesz ismeretlen a make program használata. Az 
alaprendszer fordítását és telepítését egy — a fejlesztők által 
írt — Makefile vezényli le, feladatunk ennek a folyamatnak az 
elindítása, illetve (nem túl megterhelő) megfigyelése. Felme- 
rülhet a kérdés, hogy ha az alaprendszer és a rendszermag 
együtt biztosít megfelelő működést, akkor mi módon tudjuk 
a lehető legkevesebb ideig tartó kiesést elérni. Megnyugtatok 
mindenkit, erre megvannak a megfelelő módszerek, nézzük: 


$ cd /usr/src/ 

$ make buildworld 

$ make buildkernel KERNCONF-SAJAT 

$ make installkernel KERNCONG-SAJAT 


Az első sor önmagáért beszél, a többiről már írnom kell. 

A bui Idwhorld hatására készül el az új alaprendszer bináris 
tükörképe, amelyet egyelőre a /usr/obj/ könyvtárban talál- 
hatunk meg. Ennek a fordításnak az ideje a gép tudásától 
függően 10-15 perctől (többprocesszoros nagyszámítógép) 
akár több napig is eltarthat (egy olcsó 486-os PC). A fordítás 
sikeres végét arról ismerhetjük meg, hogy visszakaptuk 

a parancssort, és az utolsó egy-két képernyőnyi szövegben 
nem látjuk az ,error" szót. Hasonló feladatot lát el 

a bui Idkernel is, amelynek van egy paramétere, mégpedig 
annak a konfigurációs állománynak a neve, amely az új 
rendszermag beállításait tartalmazza. Ezt el is hagyhatjuk, 
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ekkor GENERIC rendszermagot fogunk fordítani, amely az 
esetek nagy részében jó kompromisszum. A rendszermag 
fordítása nagyjából negyedannyi időt vesz igénybe, mint az 
alaprendszeré. Az utolsó parancs a lefordított rendszerma- 
got telepíti a helyére, ezáltal a következő rendszerindításkor 
már az új rendszermag fogja működtetni a gépünket. Ezen 
kívül semmi lényeges módosítás nem történt a rendszer- 
ben, minden úgy működik, ahogy eddig tette: az alaprend- 
szer változatlan, az új rendszermag pedig nem aktív, hiszen 
ehhez újra kell indítanunk a gépet. A fordítások befejezté- 
vel kiválasztunk egy kellemes és tervezett időpontot az újra- 
indítás elvégzéséhez, amikor képesek vagyunk a konzolhoz 
fizikailag hozzáférni, mivel az elkövetkező pár perces mun- 
kát mindenképpen az úgynevezett singleuser módban kell 
elvégeznünk. lermészetesen lehetőségünk van mudltiuser 
módban is elvégezni, azonban ez nem támogatott a fejlesz- 
tők részéről, így előfordulhatnak nem várt komplikációk. 

A singleuser módot (jelenleg) a negyedik menüponttal vá- 
laszthatjuk ki, amikor újraindítjuk a gépünket. 


$ cd /usr/src 

$ mergemaster -p 

$ make installworld 
$ mergemaster 


Új fogalom jelent meg: ez a mergemaster, amely összetett fel- 
adatot hajt végre, az új alaprendszer által megkívánt változ- 
tatásokat fésüli össze az aktuális beállításokkal. Nem árt 

a program futtatása előtt a /etc/ könyvtár archiválása, bár 
még nem találkoztam olyan programhibával, amely bármi 
kárt tett volna (de mint tudjuk: a FreeBSD ördög nem al- 

szik :). Az első mergemaster elmenti az aktuális állapotot, 
amelyet az instal Ilw or1d módosítani fog. A második 
mergemaster feladata, hogy felderítse és elvégezze a beállítá- 
sok módosítását, persze a rendszergazda jóváhagyásával. 
Ezen utóbbi tevékenység nem vesz el pár percnél több időt, 
így egy éles rendszer kiesése mindössze ennyi idő lesz. Siker 
esetén — egy megismételt újraindítás után — már az új, friss 
és ropogós FreeBSD alaprendszert vehetjük használatba. 


Programok telepítése 

Ha többet szeretnénk kihozni a FreeBSD rendszerből (és mi- 
ért ne szeretnénk), mint az alaprendszer használata, akkor 
programokat kell telepítenünk. Erre sok lehetőségünk van, 
amelyek között szabadon választhatunk belátásunk szerint. 


A sysinstall használata 

Legegyszerűbb módja a programtelepítésnek a sysinstal1 
nevű mindenes használata. Mint már említettem, 

a , Configure" menüpont , Packages" almenüjében, a megfe- 
lelő telepítési médium kiválasztása után, egyszerűen kijelöl- 
jük a telepítendő programcsomagokat. Ezek előre le vannak 
fordítva (a használt architektúra , leggyengébb" láncszemé- 
re), ezért azonnal telepíthetők. A módszer előnye az azon- 
nali használatbavétel, hátránya az optimalizált fordítás hiá- 
nya, amely 5-509 teljesítményveszteséget is okozhat. Kez- 
dőknek bátran ajánlom ezt a módszert. 


A pkg. add program 

Ha nem szívleljük a menürendszer által vezérelt programok 
használatát, akkor a pkg add programot nekünk találták ki. 
Ezzel ugyanis azt végezhetjük el, amit a sysinstal 1 is meg- 
tenne, de lassú hálózati kapcsolaton át sokkal hatékonyabb 
és gyorsabb lehet a munkánk. A program használata egysze- 
rű, bár ismernünk kell a telepítendő csomag pontos nevét: 

$ pkg.add -r mozilla 


nLetöltjük, kicsomagoljuk, lefordítjuk, feltelepítjük" 
módozat 

Ez a módszer a legősibb programtelepítési mód UNIX rend- 
szerek esetén. A programok nagy része C/C-t -4 nyelven meg- 
írt forráskód formájában áll rendelkezésre, amelyeket haszná- 
lat előtt le kell fordítani. Ez több okból alakult így, részben 

a UNIX rendszerek változatos hardverei miatt, részben a nyílt 
forrás okán. Egy programot több tíz architektúrára előfordíta- 
ni időigényes és felesleges munkának bizonyult, a programok 
forrása pedig többnyire rendelkezésre állt. Így célszerűen le- 
töltötték-megszerezték minden szükséges program forrását, 
ezeket lefordítottak a használat helyén, majd , feltelepítették" . 
Sajnos ez a módszer egyre összetettebbé vált a programok 
méretének növekedésével, illetve egyre nehézkesebbé — prog- 
ramozásban kellően nem gyakorlott — rendszergazdák számá- 
ra is. Ez utóbbi esetben nem a letöltés vagy a kicsomagolás 
okozott gondot, hanem a forráskód lefordítása. Ehhez ugyan- 
is magas szinten érteni kellett a programok fordításához, illet- 
ve a C/Ct-t nyelvhez, ha egy nem telepített programkönyv- 
tárra vagy forrásfejlécre hivatkozott az aktuális program. 

A probléma megoldására olyan programot fejlesztettek ki, 
amely felderíti és leellenőrzi a telepítendő program igényeit, 

s ezeket hiányát közérthető módon jelzi, ez a configure. 

Jó esetben egy ilyen telepítés csak pár utasításunkba kerül: 


cd /usr/local/src/program/ 
. /configure 

make 

make test 

make install 

make clean 
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Sajnos sok olyan programmal találkozni újabban, amelyek 
nagyon erőteljesen hozzá vannak láncolva a Linux konven- 
ciókhoz. Ezek sok szenvedés árán fordíthatók le FreeBSD 
alá, mivel olyan dolgokat keresnek olyan helyen, amelyek 
FreeBSD esetén egyáltalán nincsenek, vagy azon a helyen 
nem léteznek. Remélhetőleg idővel a fejlesztőknek sikerül 
közös nevezőre jutniuk. 
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A ports , adatházis " használata 

A ports adatbázis lényege, hogy a programcsomagok karban- 
tartói a telepítendő programokról kiegészítő információkat 
gyűjtöttek egybe, amelyek jelentős segítséget adhatnak a for- 
dítás során. Az előkészületek azonosak az alaprendszer kar- 
bantartásához: az adatbázist letöltjük a CVS kiszolgálóról, 
ehhez el kell készítenünk egy sup állományt, amely a ports 
frissítéséért felelős (ennek neve lehet például ports-sup): 


:default host-cvsup.hu.freebsd.org 
:default base-/usr 

:default prefix-/usr 

:default release-cvs tag—. 
:default delete use-rel-suffix 
:default compress 


ports-all 


Általában az éles szeműeknek is csak egyetlen különbség 
tűnik fel az src-sup állományhoz képes: src-all helyett ports- 
all van az állomány végén. Azonban érdemes megnézni 

a tag opciót is, ahol most egy darab pontot láthatunk csak, 
ugyanis a ports független a FreeBSD alaprendszer verziójá- 
tól! A többinek már mennie kell, mint a karikacsapásnak: 

ki kell adnunk a cvsup ports-sup parancsot, amely 

a /usr/ports/ könyvtár alá szinkronizálja a legfrissebb adat- 
bázist. Jogos kérdéseket vélek hallani: , De mire jó ez a 300 
megabágt letöltött adat?!" A kérdés jó! 

A ports adatbázis (jelenleg) közel 11500 program adatait tar- 
talmazza, amelyeket felkészítettek a FreeBSD alatti kompli- 
kációktól mentes fordításra. löbb tíz kategória közül vá- 
laszthatunk, amelyek sok száz - a kategóriába tartozó — 
programot tartalmazhatnak. Például a BitchX IRC kliens- 
program feltelepítéséhez bele kell lépnünk a /usr/ports/ 
irc/bitchx könyvtárba, ahol körülnézve alig látunk néhány 
állományt. Ez így van rendjén, ugyanis csak az összefoglaló 
információkat tudhatjuk meg a kiválasztott programról 
(pkg-descr), a feltelepítendő állományok nevét és helyét 
(pkg-plist), valamint egy Makefile is ott árválkodik. A prog- 
ram forrásának nyoma sincs, és ez így van rendjén. Gon- 
doljunk csak bele, hogy 11500 program forrása mekkora he- 
lyet igényelne! A make parancsot kiadva tudjuk a program 
telepítését megkezdeni, s a gépezet működni kezd: letölti 

a megadott helyek egyikről a program forrását: 


55 1rc1i1-pana-1.1-final.tar.gz doesn-t seem to 
ssexist in /usr/ports/distfiles/. 

55 Attempting to fetch from ftp://ftp.bitchx.org/ 
ss pub/BitchX/source/ 


Amint láthatjuk, először a /usr/ports/distfiles/ könyvtárban 
keresi a letöltendő állományt, amely könyvtár egyfajta 
gyorsítótár funkciót valósít meg. Ha elfeledkeznénk erről 

a könyvtárról, könnyen előfordulhat, hogy valami rejtélyes 
oknál fogva elfogy a hely a /usr/ fájlrendszeren. Ilyen eset- 
ben elsősorban erre a könyvtárra gyanakodjunk (második 
gyanúsítottunk a /usr/obj/ lehet, amely az alaprendszer le- 
fordított állományainak ad helyet). 

A letöltött forrás kicsomagolásra kerül, s innentől azonos 
módon járunk el, mint az előző módszer: lefordítjuk és fel- 
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telepítjük a kívánt programot. Látható, hogy a felmerült 
problémák nagy részét sikerült megoldani, mivel nem kell 
keresgélni és letölteni a programok forrását, illetve teljesen 
biztosan működni fognak FreeBSD alatt. lovábbá már nem 
kell kézzel vadászni a szükséges komponenseket, mivel 

a ports adatbázis már tartalmaz információkat a függősé- 
gekról, így rekurzív úton automatikusan feltelepítésre kerül 
minden szükséges csomag. 


A portinstall használata 

Szinte hallom a morgolódást, hogy , Ennyi? Mi ebben a rend- 
szergazdabarát?!" Igen, én is ezt kérdezgettem magamtól, 
amíg rá nem találtam az , egyetlen igaz útra": a portinstall 
használatára. Aki egyszer ráérez az ízére, soha nem feledi. 
A portinstal! a /usr/ports/sysutils/portupgrade/ könyvtár- 
ból telepíthető fel (mivel azonos a portupgrade program- 
mal), természetesen az előző részben megismert módon. 

A programok telepítésének (eddigi) legkényelmesebb mód- 
ja a portinstal Il program használata, amely jelentősen 
megkönnyíti ezt a tevékenységet. Első használatkor a prog- 
ram elkészíti a saját adatbázisát a feltelepített és a feltelepít- 
hető csomagokról, ez sok ideig is eltarthat. Alapvetően 
könnyű a használat, egyszerűen meg kell neveznünk a kí- 
vánt program nevét, portinstal 1 apache, ezzel elindul 

a megnevezett program telepítése. Feltéve, ha van ilyen, il- 
letve csak egyetlen ilyen nevű programot talál a portinstall. 
lelepíthető program hiányában egy hibaüzenetet kapunk, 
amely arról tájékoztat, hogy nincs ilyen nevű program 

a ports adatbázisban. Több találat esetén sorban megkérde- 
Zi a feltelepítendő program pontos nevét, és verziószámát: 


Found 2 ports matching f"apache" : 
ww/apache13 

wwv/apache2 

"ww/apache13"? [yes] n 
"ww/apache2"? [lyes] y 


szé 


Install 
Install 


A telepítés innentől teljesen azonosan történik a ports adatbá- 
zis használatával, eltekintve attól, hogy nem kell más paran- 
csot kiadnunk, a portinstal l] mindent megold és elvégez. 
Érdemes a telepítéskor mindig rákérdeztetni a telepítendő 
programokra, ezzel sok felesleges munkától szabadulunk 
meg (nem kívánt program eltávolítása); ezügyben a -i op- 
ciót kell használnunk. Fontos lehet a -P opció ismerete is, 
amely kombinálja az előfordított csomag telepítését 

a portinstal1 előnyeivel: a program megpróbálja letölteni 
a kívánt csomag előrefordított állományát, s csak akkor 
használja a ports adatbázist, ha nincs ilyen előfordított állo- 
mány. Ezzel időt tudunk megspórolni, ha gyorsan kell egy 
programot telepíteni. 


A portupgrade használata 

A telepítések mellett nagyon fontos a telepített programok 
naprakészen tartása. Ehhez alapvetően a ports adatbázis 
frissítése szükséges, amelyet a cvsup ports-sup parancs ki- 
adásával tehetünk meg. Ekkor a frissítendő programot el 
kell távolítani, majd a helyére feltenni az újabb verziót. Fel- 
téve, ha van újabb, viszont ennek eldöntése kicsit , favágó" 
munka, mert egyenként végig kell lépkednünk a telepített 
programokon, és megnézni, hogy van-e újabb. 
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Ezt az idegőrlő munkát teszi átláthatóvá és egyszerűvé 

a portupgrade program, ugyanis végignyálazza helyettünk 
a feltelepített Programokat; majd utánanéz, hogy van-e 
újabb verzió. Gyakorlatilag csak a portupgrade -a paran- 
csot kell kiadni, óvatosabbak a -i opciót is használhatják 
portupgrade -a -1. 

Általános esetekben némi molyolás után listát kapunk a fel- 
telepített és a frissíthető programokról. Előfordulhat azon- 
ban, hogy a programcsomagok függőségei a frissítés során 
(aljas módon :) megváltozhatnak. Ekkor egy (első látásra ri- 
asztó) üzenetet láthatunk, mint például 


Stale dependency: intlfonts-1.2.1 -5 XFree86- 
—3.3.6 11 - manually run "pkgdb -F" to fix, or 
ss specify -O to force. 


Nem kell megijedni, csak futtatnunk kell a pkgdb -F 
programot, amely a segítségünket igénybe véve kijavítja 
a hibát. 


Stale dependency: intlfonts-1.2.1 -5 XFree86- 
5 3.3.6 11 (x11/XFree86) : 
New dependency? (? to help): 


A megoldás egyszerű, az Xfree$6 csomag helyett már Xorg 
néven kell a grafikus felületre hivatkozni: 


New dependency? (? to help): xorg-6.7.01 
Fixed. (-5 xorg-6.7.0 1) 


Ugye, nem is volt olyan bonyolult? Figyelni kell arra, hogy 
a függőség megadásánál pontosan nevezzük meg a progra- 
mot, annak minden verziószámával együtt. Sajnos ez 

a ,hiba" ritka, és ennél fogva zavarba ejtheti a gyanútlan 
FreeBSD rendszergazdát. Ennél is ritkább, ha szinte egy 
komplett nyomozati apparátusra van szükségünk, ha fel 
szeretnénk deríteni a hiba okát, mivel igencsak rejtélyes le- 
het a függőségek szövedéke. Érdemes gyakran frissíteni 

a ports adatbázist, majd azonnal futtatni a pkgdb -F paran- 
csot, mivel hosszabb idő (hónapok) kihagyása után esélyte- 
len lehet a függőségek kibogozása. 

A fenti problémák nélkül egy listát kapunk a telepített 
programokról, amelyeknek nagy részét nem kell frissíteni, 
mert nincs belőlük újabb verzió. lermészetesen felkérhetjük 
a -f opcióval, hogy minden telepített programot fordítson 
újra: előrefordított programok esetén megtehetjük, ha ren- 
geteg felesleges időnk van. 


"xx No need to upgrade "xpdf-3.00 37 (Cs - xpdf- 
53.00 3). (specify -f to force) 

x-z No need to upgrade "urwfonts-1.07 (C- urwfonts- 
1.0). (specify -f to force) 


Néhány csomag esetén viszont megkapjuk a kérdést: 


—-s  Upgrade of java/jdki14 started at: Wed, 03 Nov 
32004 19:39:06 --0100 

—-s5  Upgrading "jdk-1.4.2p6 5" to "jdk-1.4.2p6 67 
sz (jJava/jdk14) 

OK? [yes] 


Elég egy ENTERT ütni, s elindul a kiválasztott csomag fris- 
sítése, amely során a portupgrade elkészíti az újabb ver- 
zió telepítésre kész csomagját, kiveszi a csomaglistából 

a régi programot, elmenti a régi csomag minden telepített 
állományát, majd megpróbálja az újat telepíteni. Ha sike- 
rül, akkor nincs már semmi gond, ettől kezdve az újabb 
programot használhatjuk. Probléma esetén visszakerül 

a helyére a régi program, így a hibák nem okoznak feles- 
leges leállást. 


Program keresése a ports adatbázisban 

Gyakran előfordul az a helyzet, amikor egy bizonyos fel- 
adatra keresünk megfelelő programot. Egyik lehetséges 
megoldás, hogy a számunkra érdekes kategóriát nézzük 
át, és bízunk a szerencsénkben: hátha belebotlunk a ke- 
resett programba. Sokkal célravezetőbb megoldás, ha 

a /usr/ports könyvtárba lépve utasítást adunk erre a kere- 
sési feladatra. Ez egyszerűen egy megfelelő make parancs 
kiadása lesz: 

$ make search key-open I] less 


Ezzel az utasítással a program végignyálazza a teljes ports 
adatbázist, és minden olyan csomagot kiír, amely neve, 
rövid vagy bővebb leírása tartalmazza a megadott kulcsot, 
amely jelen esetben az , open" szó. A , less" programot 
azért érdemes futtatni, mert sok száz találat is lehet, ame- 
lyek hamar felfutnak a képernyőn. Előfordulhat, hogy 
olyan találatot is olvashatunk, amely látszólag nem tartal- 
mazza a kulcsszót: 


Port: 120-1.08 1 

Path: /usr/ports/archivers/1zo 

Info: Portable speedy, lossless data compression 
sz library 

Maint:  portsíúFreeBSD.org 


Nem kell azonban aggódni, a keresés kiválóan mű- 
ködik, a program bővebb leírása tartalmazza az 
,open" kulcsszót, egyszerűen csak ez a bővebb leírás 
nem jelenik meg. A kapott listát végigkövetve hamar 
megtalálhatjuk azt a programot, amelyet fel szeret- 
nénk telepíteni. 


A telepített programok adatbázisa 

A telepített programok leírásai egy speciális adatbázisban 
foglalnak helyet, amelyet a /var/db/pkg/ könyvtárban talá- 
lunk. Nem kell hozzá speciális program, ugyanis egy prog- 
ram - egy könyvtár elven találjuk meg az összes regisztrált 
(telepített) program jellemzőit. 

lermészetesen létezik külön program, amely kényelmeseb- 
bé teszi ezen adatbázis használatát, ez a pkg. info, amely- 
nek annyi a dolga, hogy a paraméterében megkapott cso- 
magról információkat szolgáltasson: 


$ pkg.info hu-openoffice-1.1.3 
Information for hu-openoffice-1.1.3: 


Comment: Integrated w ordprocessor/ 


s dboase/spreadheet/drawing/chart/ 
s browser 
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Programok törlése 

Eljöhet az idő, amikor egy telepített program feleslegessé 
válik, bár én ritkán találkozom olyan esettel, amikor progra- 
mok törlése valóban szükséges lépésnek bizonyul (gondol- 
junk csak a merevlemezek szinte határtalan kapacitására). 
Az egyik törlési megoldás igazából nem törlés, hanem 

a program írissítése során alkalmazott technikai megoldás, 
amely azonban önmagában is használható: pkg. deinstal1. 
Ekkor a telepített állományokat nem töröljük a helyükről, 
csak a telepített csomagok adatbázisából kerülnek ki, így 
azonos program újabb verziójának telepítésénél nem lesz 
akadálya. Nem szép megoldás, ezért ne nagyon használjuk 
függőségi problémák megoldására. 

Véglegesen a pkg delete parancs segítségével tudjuk töröl- 
ni a kívánt programot, ekkor a telepített programok adatbá- 
zisa alapján a törlődnek a nem módosított állományok. 

Ez utóbbi azért fontos, mert különben a programok beállítá- 
sai is törlődnének: 

$ pkg delete lsof-4.73.1 


A programnak hibátlan lefutás esetén nem lesz kimenete, 
ha szeretnénk, hogy részletesen számoljon be a tevékenysé- 
géről, akkor használnunk kell a -v paramétert is. Ha nem 
tudjuk pontosan a törlendő program nevét verziószámával 
együtt, akkor használhatjuk a megszokott helyettesítő 
karaktereket is: 

$ pkg. delete lsof" 


Mind a kettő program azonos paramétereket fogad el, ame- 
lyek közül elsődlegesen a -f lehet érdekes számunkra, 
amely megadásakor a törlés akkor is végrehajtódik, ha füg- 
gőségi problémák merülnének fel. Érdemes a -r és a -R pa- 
raméterre is gondolnunk, amelyek hatására a törlés rekurzíi- 
van hajtódik végre. A -R esetén mindazon csomagok törlés- 
re kerülnek, amelyekre a megadott csomagnak szüksége 
van, ezzel biztosak lehetünk benne, hogy nem maradnak 
olyan telepített csomagok, amelyekre igazából már nincs 
más csomag felől hivatkozás (így igazából feleslegesek). 

A -r ennek ellentéte: az összes olyan csomag törlődni 

fog, amelyeknek a megadott csomagra szüksége van; 

ezzel óvatosan érdemes bánni, mert egy alapvetően szük- 
séges csomagot megadva akár az összes telepített csomag 
törlődni fog. 


Auth Gábor (auth.gaborxDenaplo.hu) 

Egy pécsi középiskolában informatikát és prog- 
ramozást oktat. Tíz éve botlott először a UNIX 
rendszerekbe, 7 év Linux használat után kapta 
el a FreeBSD lázat, amiből máig nem tudott 


kigyógyulni. 





A FreeBSD projekt honlapja 3 http:/Avww.freebsd.org, 
A magyar FreeBSD honlap 3 http:/Avww.freebsd.hu, 


A magyar BSD honlap 3 http:/Avww.bsd.hu, 
A kézikönyv magyar fordítása 
2 http:/Avww.enaplo.hu/FreeBSD/handbook/. 
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Listaablakok röptében a Tk::")HList segitségével 


A bevásárlólistától a /etc/passwd-ig grafikus külsőt kaphat bármi, ha Perl alatt 


kipróbálod a HList elemet. 


zúttal rendhagyó módon szeretnék eltekinteni az 
unalmas történelmi bevezetőtől. Miután teljesen 
nyilvánvaló, hogy a kedves Olvasó előbb a képer- 





nyőfotókat nézi meg, majd azonnal a kódra kíváncsi, tér- 
jünk rögtön a lényegre. Elöljáróban csak annyi feltételezés- 
sel élek, hogy olvasóimnak nem teljesen új az a módszer, 
amivel Per[/Tk-ban egy ablakot létre lehet hozni . Ha ez 
nem jelent gondot, akkor kattogjon az a klaviatúra, mert 
máris jön az első lista. 


$1!/usr/bin/perl -w 


use strict; 
use Tk; 
use Tk::HList; 


my $foablak - new Mainwindow (-title —s 
s "Bevasarlolista"); 


my $lista - $foablak -: HList (-width -—: 259; 
$lista -5 pack; 


my Gvasarlas - ( "tej", "kenyer", "szalami"); 
my $dolog; 


foreach $dolog (dvasarlas) í 
$lista -5 add ($dolog, -text -—5 $dolog); 
J 


MainLoop; 


A szkript három modult használ. A már jól ismert strict 
szigorú ellenőrzési módot ír elő a parancsértelmezőnek. 

A Tk a grafikus eszközkészletet (7T00IKit) teszi elérhetővé 
egy jól átgondolt objektum-orientált felületen keresztül. 
Végül a Tk: :HList a Tix (Tk Interface Extension) HList 
nevű elemét biztosítja. Ez a kiegészítés minden Tk csomag 
része, így ennek a használatával jó eséllyel nem veszítünk 
a felület-függetlenségből. 

Első lépésben példányosítjuk a Mainwindow osztályt, és 

a konstruktornak egy - jelen esetben egyetlen párból álló — 
névtelen asszociatív tömböt adunk át. Ezzel úgy hozzuk lét- 
re az ablakot, hogy azonnal be is állítjuk a címét. A kapott 
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. ábra A bevásárlólista 





2. ábra Bevásárlás több szinten... 


$foablak objektum HList elemfüggvényével hívunk életre 
egy HList ablakelemet, melynek szintén adunk kezdőérté- 
ket, ezáltal meghatározzuk a szélességét. Ezután az új, 
$1]ista objektumra meghívjuk a pack elrendezés-kezelőt. 
Semmi gond nem származik abból, hogy anélkül hívtuk 
meg a $lista pack elemfüggvényét, hogy az akár egyetlen 
listaelemet is tartalmazna. Az ablak, és minden, ami benne 
van, csak akkor jelenik meg, amikor a MainLoop-ot meghív- 
juk. A lista feltöltése a dennivalok tömbből fog történni. 
Egy foreach szerkezetben a $dolog változó sorra felveszi 
ezen tömb elemeit. A ciklus minden lefutásában hozzáad 
egy új tételt a bevásárlólistához. 

Ezen a ponton álljunk meg egy pillanatra. A HList egy 
igen sokoldalú ablakelem, és sokkal többre képes egy 
egyszerű lista megjelenítésénél. Kialakíthatunk egy hierar- 
chiát az adatelemeink között, és akár egy faszerkezettel 

is elkápráztathatjuk felhasználóinkat. Az adattagokat 

a hierarchiában egy egyedi név azonosítja, amely ponttal 
etel .zoldsegek. paprika azt jelenti, hogy a paprika 

a harmadik szinten helyezkedik el, és a közvetlen szülője 

a zoldsegek, ami az etel alatt található. 

lermészetesen nem kötelező kihasználnunk ezt a lehetősé- 
get, tehetjük az összes elemünket egy szintre. Ebben a pél- 


Voros ertek! Zold ertek! Kek ertek 


i 


ellow — Úxitít Öxítít 0 





3. ábra Színes oszlopok 





proxy /bin 
13 postgres x31 postgres tvarilib/posigres 
14 www-data x 33 www-data hgartaryw 
15 backup  x34 backup fvaribackups 
Operator fvar 


16 operator x37 
x 38 SmartList fvarilist 
x 39 ircd far 
x 41 Gnats Bug-Reporting System (admin) /variutígnats 
x 65534 65534 nobody home 





4. ábra Szöveges adatbázis megjelenítése 


dában pontosan ez történik. Az add elemfüggvény első pa- 
ramétereként megadjuk az elérési utat, továbbá kulcs-érték 
párral az elemhez tartozó megjelenítendő szöveget. Ez 

a két dolog jelen helyzetben ugyanaz, de ez nem szükség- 
szerű. Egy többszintű ábránál szinte biztos, hogy nem is így 
van. Lássunk erre is egy példát! 


$1!/usr/bin/perl -w 
use strict; 
use Tk; 


use Tk::HList; 


my $foablak - new Mainwindow (-title —s 


s "Bevasarlolista27); 
my $lista - $foablak -5 HList ( 
-width -—5 25, 
-height -—:5 15 
) -5 pack; 
my űvasarlas — ( 
L["i1tal", "nem-alkoholos7, "tej"], 
[ "etel", "alap", "kenyer" ], 
[ "etel", "felvagott", "szalami"], 
[ "etel", "zoldseg", "paprika" ], 
[ etel", "zoldseg", "paradicsom"] 
9; 
my $dolog; 


foreach $dolog (dvasarlas) ( 


for (my $elem — "7, my $1 — 0; $1 c 3; $1 44) ( 
$elem .— "7." unless ("" eg $elem) ; 
$elem .—- $$dolog L$i]; 


unless ($lista -5 infoExists ($elem)) ( 


print "Elem: " . $elem . " (" . $$dolog 
SELNTN a ha 

$lista -s add ($elem, -text —5 $$dolog 
5 [$1]; 


www.linuxvilag.hu 





print "hozzaadva. Mm" ; 


MainLoop; 


A $foablak HList elemfüggvényének meghívásakor egy- 
részt megadtunk egy további magasság paramétert 
(height), másrészt a pack-et közvetlenül a létrejövő objek- 
tumra hívtuk meg. Mivel a nyíl operátor balról jobbra érté- 
kelődik ki, ez az állítás teljesen egyenértékű az eredetivel, 
és talán egy kicsivel rövidebb. A dvasarlas tömbünk itt 
már névtelen, három elemű tömbök referenciáit tartalmaz- 
za. Ezeket a referenciákat veszi fel sorra a $dolog változó 

a foreach ciklusban. 

Minden egyes lefutásban három lépést teszünk. A második 
tömbreferencia feldolgozásakor például előbb az etel, 
majd az etel . alap, végül az etel .alap.kenyer elemet 
vizsgáljuk. Erre szolgál a belső for ciklus. Minden lépésben 
az infoExists elemfüggvény segítségével megnézzük, 
hogy az elem létezik-e, és ha nem, létrehozzuk. Itt látható, 
hogy az elérési út különbözik a megjelenített névtől. A vé- 
gén adódó fa egyes ágai nem bezárhatóak. Ha ilyesmire 
lenne szükséged, nézz utána a Tree elemnek, amely 

a HList-ből származik. 

A következő szkriptben egy több oszlopból listát láthatunk, 
sőt, még azt is megtanulhatod, hogyan lehet eseménykeze- 
lést rendelni az ablakelemhez. 


$1!/usr/bin/perl -w 


use strict; 
use Tk; 
use Tk::HList; 


my $foablak - new Mainwindow (-title —5 "Szinek"); 


my $lista - $foablak -5 HList ( 
-columns —s5 4, 
-header —5 1, 
-width -—5 25, 
-height —: 15, 
-command -—5 Véhatter beallit 


08 


$lista -5 headercreate (0, -text —5 "Sz1n"); 

$lista -5 headercreate (1, -text —5 "Voros ertek"); 
$lista -5 headercreate (2, -text -—5 "zold ertek"); 
$lista -5 headercreate (3, -text -5 "Kek ertek"); 


$lista -5 pack ( 
-expand —: 1, 


-fill -5 "both" 
Ja 
my szinek — ( "red", "magenta", "yellow", "pink", 
sz "]lightblue"); 
my $szin; 
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foreach $szin (4aszinek) ( 


my ($voros, $zold, $kek) - $foablak -5 rgb 
sz ($szin); 


$lista -5 add ($szin); 

$lista -5 itemCreate ($szin, 0, -text —s 
sz $szin); 

$lista -5 itemCreate ($szin, 1, -text —- 
sz sprintf "98x", $voros); 

$lista -5 itemCreate ($szin, 2, -text —- 
ss sprintf "9£x", $zold); 

$lista -5 itemCreate ($szin, 3, -text —s 
ssprintf "94x", $kek); 


um 


MainLoop; 


sub hatter beallit ( 
my ($szin) -— a ; 
$lista -5 configure (-background -—: $szin); 


st Lf 


Ez a szkript már valamivel összetettebb az előzőekben bemu- 
tatottaknál. Színek egy rögzített halmazát jeleníti meg táblá- 
zatos formában. Minden szín vörös, zöld és kék összetevőjét 
közvetlenül a szín neve mellett 16-os számrendszerben mu- 
tatja. Ha a felhasználó duplán kattint valamelyik elemen, 

a teljes lista az adott háttérszínt veszi fel. A színek közismert 
angol nevét használjuk a feladat egyszerűsítése végett. 

A főablak objektum HList elemfüggvényének paramétere- 
zése már közel sem olyan kurta, mint a legelső példában. 

A -columns kulccsal lehetőségünk van az oszlopok számá- 
nak beállítására. Ez alapértelmezésben 1, ezért hagyhattuk 
el eddig. Új opció továbbá a -header, mely azt határozza 
meg, hogy legyen-e fejléce az egyes oszlopoknak. Alapértel- 
mezésben 0, vagyis nincs fejléc, ezt bíráljuk felül az 1-es ér- 
tékkel. Végül a -command egy függvényt tartalmaz, melyet 
a MainLoop minden egyes alkalommal meghív, ha bármely 
elemen kettős kattintás történik. 

A fejléc tartalmának létrehozására a lista objektum 
headercreate elemfüggvénye szolgál. Paraméterezése ön- 
magáért beszél. Először az oszlop sorszámát kell megad- 
nunk, ahol az első oszlop a 0. indexű. Utána egy már jól is- 
mert -text kapcsolóval beállíthatjuk a megjelenítendő szö- 
veget. Ezúttal a pack-et sem üres paraméterlistával hívtuk 
meg. A megadott két beállítás hatására az ablakelem önmű- 
ködően kitölti a tőablakot, azaz a felhasználó bárhogy mó- 
dosítja az ablak méretét, a listánk széltében és hosszában is 
követi a változtatásokat. 

A lista feltöltése ismét egy foreach szerkezettel történik, ám 
most fontos, hogy a (szinek tömb szabványos angol színne- 
veket tartalmaz. A ciklus hasának első utasításában ugyanis 
a tömb sorra következő elemével meghívjuk a főablak rgb 
függvényét. Ez utóbbi a paraméterként kapott szín három 


et 


összetevőjét tartalmazó tömbbel tér vissza. Így a $voros, 
$zold és $kek változók a megfelelő értéket kapják. 
Ezután az add elemfüggvénnyel csak létrehozzuk az ele- 


met, szöveget még nem rendelünk hozzá. Ezt a feladatot 
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ugyanis az i temcreate függvényre hárítjuk, amely egy 
meglévő listaelem celláinak kitöltésére használható. Első 
paramétere a listaelem azonosítója, második az oszlop sor- 
száma, utána pedig bármi, ami az add-nél is használható. 
C-hez szokott szemeknek nem meglepő, hogy a színössze- 
tevők 16-os számrendszerbeli értékének előállításához 

a sprintf függvényt használtuk. 

Végül térjünk ki egy kicsit az eseménykezelésre. Mint emlí- 
tettem, még a HList ablakelem létrehozásakor meghatároz- 
tunk egy eseménykezelőt a -command kapcsolóval. Ezt 

a MainLoop hívja meg amennyiben a felhasználó duplán 
kattintott. Azon elem azonosítóját, melyen a kattintás tör- 
tént, paraméterként megkapja a függvényünk. Vagyis 

a hatter beallit függvény első utasításában a A nevű, 
paraméterlistát tartalmazó tömb első elemének kinyerésével 
annak a színnek a nevéhez jutunk, melyre a felhasználó 
kettőt kattintott. Ezután egy configure függvénnyel ér- 
vényre juttatjuk a kívánt hatást. 

Utolsó példánkban egy általános, szöveges alapú adat- 
bázisok megjelenítésére használható szkriptet szeretnék 
bemutatni. 


$1!/usr/bin/perl -w 


my $hatarolo — ":"; 


die "Hasznalat: " . $0 . " íkulcst fregkifjn" 
unless GARGV —— 2; 


use strict; 
use Tk; 
use Tk::HList; 


my 4atalalatok —-— OO; my $mezoszam — 0; 


while (-xSTDIN5) ( 
chomp; my (Cmezok -— split $hatarolo; 
if ($mezokL$ARGV[O] - 1] -—- /$ARGV[1]/) ( 
push atalalatok, $. . $hatarolo . join 
3 $hatarolo, (Gmezok; 
$mezoszam — (mezok 1f ($mezoszam c (mezok); 


J 


$mezoszam -4-; 


my $foablak - new Mainwindow ( 
-title —s5 7/7 . $ARGV[1] . "7 a " . 
sz- mezoben", -borderwidth —: 2 


$ARGV[017 


03 


my $lista - $foablak -5 Scrolled ( 
"HList", 
-scrollbars —5 "se", 
-columns -5 $mezoszam, 
-header -—5 1, 
-width —s5 25, 
-height —5 15, 
-command -—5 Véduplakatt 
44 


$lista -5 headercreate (0, -text —5 "N"); 
$lista -5 pack ( 

-expand —: 1, 

-fill —5 "both" 
JA 


foreach (atalalatok) ( 
my (Gmezok - split $hatarolo; 
$lista -5 add ($mezok[0]); 
for (my $i — 0; $i c $mezoszam; $i 44) ( 
$lista -5 itemCreate ($mezokL[lO], $1, -text —- 
s $mezok[$i]); 


MainLoop; 


sub duplakatt ( 

my ($azonosito) — a ; 

for (my $i — 1; ; $i 4) ( 
print $lista -5 itemcget ($azonosito, $i, 
text); 
last if ($i -—— $mezoszam - 1); 
print $hatarolo; 

J 

print $/; 

exit; 


A szkript a határoló karaktert egy változóban tárolja, így az 
egyetlen sor módosításával változtatható. A szabványos be- 
menetről olvassa az adatokat, és önállóan meghatározza az 
oszlopok számát. Az adatsorok közül kizárólag azokat jele- 
níti meg, melyeknek adott sorszámú mezője illeszkedik 

a szintén adott szabályos kifejezésre. Az oszlopok sorszá- 
mozása 1-től indul. A grafikus megjelenítés után a felhasz- 
náló duplán kattinthat bármely elemen. Amennyiben így 
kiválasztott egyet, az megjelenik a szabványos kimeneten, 
és véget ér a program. 

A use-al kezdődő soroktól kezdve nézzük át a program mű- 
ködését. Két fő ciklus köré szervezzük a működést. Előbb 
beolvassuk az összes adatot egy tömbbe, majd egy követke- 
ző ciklusban megjelenítjük valamennyi elemet. Az első lé- 
pésben két változót töltünk fel: a atalalatok tömböt és 

a $mezoszam változót. A Atalalatok a keresés eredményét 
tartalmazza, minden találatot kiegészítve egy sorszámmal. 
A $mezoszam a találatok legtöbb mezőt tartalmazó sora me- 
zőinek számát tartalmazza. 

A while ciklus addig olvas a szabványos bemenetről, amíg 
talál ott adatot. Minden lefutásban egy sort dolgozunk fel. 
Először levágjuk a sorvége jelet, majd a határoló karakterek 
mentén felszeleteljük a sort, és a mezőket kigyűjtjük egy 
(mezok tömbbe. Ezután ellenőrizzük, hogy a rekord kielégíi- 
ti-e az általunk támasztott feltételeket. A szkript első para- 
métereként kapott mezőszámot eggyel csökkentjük, és 

a (mezok ezen indexű elemét vizsgáljuk. 

Ezáltal ha a paraméter 1 volt, az itt 0-át jelent, ha 2, akkor 1- 
et, stb. Azaz a felhasználó számára a mezők sorszámozása 1- 
től indul, és pont ez volt a cél. Tehát a (mezok megfelelő ele- 
mének kiválasztása után mintaillesztést végzünk rá a máso- 
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dik paraméterrel. Ha ez sikeres volt, veremként használva 

a (atalalatok tömböt, betesszük a visszaépített sort, az ele- 
jén kiegészítve a találat helyével. Erre azért van szükség, 
mert ez biztosan egyedi azonosítója az adott rekordnak. 

A $mezoszam-ot minden sikeres mintaillesztés után hozzá- 
igazítjuk a mezők számához, amennyiben az szükséges. 

A ciklus végén pedig megnöveljük az értéket eggyel, hiszen 
minden rekordot kiegészítettünk egy, az eredeti állomány- 
ban elfoglalt sor számát tartalmazó mezővel, így a legszéle- 
sebb rekord is biztosan eggyel szélesebb lett. Ezzel beolvas- 
tuk az összes adatot, jöhet a megjelenítés. 

Először is létrehozzuk a főablakot. A címben jelezzük 

a szkript paramétereit, vagyis a keresés szempontjából 
kulcs mező számát és a reguláris kifejezést. lovábbá a 
-borderwidth kapcsolóval meghatározzuk az ablak széle 
és a hozzá legközelebb eső ablakelem közti távolságot 
képpontokban. Vagyis jelen esetben az ablakban használt 
egyetlen elem, a lista és az ablak széle között lesz egy 

2 képpont vastag üres keret. 

Mivel görgetősávokat is szeretnénk létrehozni, ezúttal nem 
a HList elemfüggvényt hívjuk meg. A Scrol led segítségé- 
vel az áhított görgetősávokkal kiegészített elem jön létre, 
mindössze azt kell meghatároznunk, hogy hol helyezkedje- 
nek el a sávok. Az elem neve után a -scrol Ibars kapcsoló- 
val égtájak angol nevének kezdőbetűivel adhatjuk meg 

a pozíciót. Jelen esetben a dél (south) és a kelet (east) beállí- 
tással élünk. A további paraméterekkel már korábban meg- 
ismerkedtünk. Csak az első oszlopnak adunk nevet, ez jelzi 
az adatok forrásában elfoglalt sor számát. 

Ezután egy foreach szerkezettel végiglépkedünk 

a atalalatok tömbön. A kevesebb változó használata érde- 
kében az alapértelmezett változót, a $ -t használjuk futó 
változóként, ahogy ezt a whi le ciklusnál is tettük. Minden 
lefutásban újból szétbontjuk a rekordot, hozzáadjuk a lista- 
elemhez, és kitöltjük a cellákat. Ezáltal a listánk pontosan 

a keresésnek megfelelő elemekből fog állni. 

Végül a duplakatt függvény meghatározása következik. 
Ezen eseménykezelő a szkript élete során jelen esetben csak 
egyszer fut le, hiszen egy kettős kattintás után a rekordot 
kiírja a szabványos kimenetre, és kilép. A kiíratásnál már 
nem jelenítjük meg a korábban felhasznált sorszámot, ezért 
indul 1-től a for ciklus. Az i temcget segítségével kinyerjük 
a megadott cella tartalmát, és az utolsó lefutást leszámítva 
egy elválasztókarakterrel együtt írjuk ki. Legvégül egy sor- 
vége karakter nyomtatását követően kilépünk. 

Remélem, hogy a példák kellően érzékletesek voltak ahhoz, 
hogy a HList nyújtotta lehetőségeket megfelelő részletes- 
séggel bemutassam. Kisebb jártasság megszerzése után va- 
lóban percek alatt lehet grafikus külsőt készíteni egysze- 
rűbb szkripteknek, s mivel a Perlt alapvetően szöveges fel- 
adatok megoldására készítették, a HList igen sok helyen 
alkalmazható. Sok sikert a további kísérletezéshez, akinek 
pedig kérdése van, írjon bátran! 


Fülöp Balázs tadminoguardware.com) 

21 éves, imádja a lúró Rudlit, a Debian Linuxot 
és a teheneket. Kedvenc Írója Slawomir Mrozek. 
Leginkább a számítógépes hálózatok biztonsága 
érdekli. A BME VIK műszaki informatikus 

szak hallgatója. 
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PHP5 - Uj generáció 4-2. rész) 


. . avagy hogyan használjuk okosan az osztályokat és objektumokat PHP 5-ben. 


ikksorozatom előző részében képet kaphattunk 
C arról, hogy valójában mik is azok az objektumok, 

milyen tulajdonságaik, PHP vonatkozású különle- 
gességeik vannak, illetve néhány példaprogramon keresz- 
tül megismerkedhettünk a konkrét használatukkal is. 
Ebben a részben központi szerepet kap az objektumköz- 
pontúság savát-borsát adó öröklődés, az ezzel kapcsolatos 
elvont (abstract) osztályok és felületek (interface) létrehozá- 
sa, alkalmazása, valamint egy-két különleges tagfüggvény 
használata. 


Vágjunk bele — mi is az az öröklődés 

Az objektumközpontú programozás egyik ismérve a nagy- 
fokú újrahasznosíthatóság. Ezt egyrészt annak köszönheti, 
hogy ezek a jól beburkolt, jól felépített objektumok kompo- 
nensekként viselkednek, remekül lehet velük LEGO-zni. 
Másrészt ezeket az objektumokat egymással rokoni kapcso- 
latba állíthatjuk. A gyakorlatban ezt hívják öröklődésnek. 
Ha egy objektum egy másik (szülő)objektumtól örököl 
(gyermekobjektummá válik), akkor megkapja annak min- 
den tulajdonságát és tagfüggvényét - a láthatóság által 
megfogalmazott feltételek mellett természetesen. 

Az örökölt tagfüggvények teljes értékűen használhatók, 
felülírhatók, átalakíthatók, s új tagfüggvényeket adha- 
tunk az osztálynak, egyszóval programozóként igen 
nagy szabadságot élvezünk, s mindemellett az ős összes 
képességét kihasználhatjuk. Lássunk erre egy példát, 
vegyük az előző epizódban bemutatott négyzet osztályt, 
kissé átalakítva 


class Negyzet í 
protected $oldal -— 0; 


public function oldalHossztBeal lit($ertek) ( 


$this-soldal-$ertek; 


public function terulete) ( 
echo $this-soldal"$this-soldal; 


Közben a programunkban szeretnénk speciális négyzetek- 
kel, rombuszokkal foglalkozni. Tudjuk, hogy a négyzetek 
és a rombuszok hasonlóak abban, hogy minden oldaluk 
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egyenlő, de a rombusz esetében fontos az oldalak által be- 
zárt szög, S a területe is másként számítandó. Használjuk ki 
a hasonlóságokat, és csak a különbségeket valósítsuk meg. 


class Rombusz extends Negyzet ( 
protected $szog — 0; 


public function szogetBeallit($szog) ( 
$this-:5szog-$szog; 


1) 


public function teruleteO) (1 
echo $this-soldal"sin($this-5szog)" 
s $this-soldal; 


Nos, ebben a példában felülírtuk a területszámító algorit- 
must, és az új tagfüggvény hozzáadásával elintéztük az ol- 
dalak által bezárt szög kezelését. Ha jól megnézzük, meg- 
spóroltuk az oldalak kezeléséért felelős függvények megírá- 
sát, az osztályunk mégis teljes értékű. Fontos tény továbbá, 
hogy megmaradt az eredeti négyzet osztályunk, s nincs 

a kódunkban ismétlés. 

Az így megspórolt munka természetesen nem túl sok, 

de ez a példa igen egyszerű. Említést érdemel még a válto- 
zók előtti protected módosító: Most már láthatjuk, hogy 
mire jó: az ilyen változók elérhetők az örökös osztály belse- 
jéből, de csak onnan. 


A konstruktorok, destruktorok, és az öröklődés 

PHP 5-ben ha az ősosztályunknak volt egy konstruktora, 
majd az abból örököltettünk másik osztály esetében nem 
határoztunk meg ilyen tagfüggvényt, akkor a példányosítás 
során az ősosztály konstruktora automatikusan meghívó- 
dik, lefut, elvégzi a szükséges lépéseket. 

Ha azonban az örököltetett osztály is kapott konstruktort, 
akkor az ősosztály konstruktorának meghívásáról ma- 
gunknak kell gondoskodnunk (ha szükséges). Ez azért van 
így, mert ellenkező esetben jelentősen meg volna kötve 

a kezünk a származtatásokat illetően. Lássunk erre is egy 
példát, módosítsuk az ősosztályt. Az előző cikkben is is- 
mertetett módszer szerint adjunk hozzá egy konstruktort, 
amely beállítja az oldalhosszt. 


et 


class Negyzet í 
protected $oldal -— 0; 


public function , construct($oldal) ( 
$this-soldalHossztBeallit($oldal); 


public function oldalHossztBeal lit($ertek) ( 
$this-soldal-$ertek; 


public function terulete) ( 
echo $this-soldal"$this-soldal; 


Ilyenkor ugye a példányosítás után nem kell bíbelődni az 
oldalhossz beállításával, elintézhetjük a dolgot egy lépés- 
ben is. Na de mi van ilyenkor az előbbiekben bemutatott 
örökössel? Szeretnénk, ha az is egy lépésben elvégezné 
ezeket a módosításokat, de mint tudjuk, az oldalhossz ke- 
zelésével nem is foglalkoztunk, az az ősosztály feladata. 
Nézzük! 


class Rombusz extends Negyzet í( 
protected $szog — 0; 


public function , construct($oldal,$szog) í 
parent::  construct($oldal); 
$this-sszogetBeallit($szog); 


public function szogetBeallit($szog) ( 
$this-:5szog-$szog; 


public function terulete0) ( 
echo $this-soldals"sin($this-sszog)"$this-s 
sz oldal; 


Látható, hogy az oldalkezelés továbbra is az ősé maradt. 

Mi csupán annyit tettük, hogy megkértük az örökös belsejé- 
ből, hogy foglalkozzon az ő érdekeltségébe tartozó adatok- 
kal. Erre szolgál az a bizonyos parent előtag a scope C: :) 
operátorral: az ősosztály függvényeire hivatkozhatunk 
vele. Ez természetesen csak akkor érdekes, ha felülírunk 
egy függvényt, ugyanis ha ezt nem tesszük, a $this-- 
függvénynévŐ) módon elérhetjük, mint az osztály saját 
tagfüggvényét. Ha azonban az öröklés során felülírjuk, 

és úgy szeretnénk hivatkozni, az előbbi módszerrel egy 
végtelen rekurzív függvényt kapunk, ami bizonyos, hogy 
senkinek sem jó. 

A parent::  constructO hívás helyett jelen esetben 

a $this-soldalHossztBeállítO tagfüggvényt is használ- 
hattuk volna, ám úgy logikailag összefolyna a két objek- 
tum. Ez most még egy sokadrangú döntés, amely bonyolul- 
tabb esetekben azonban életet menthet. 
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Függvénytúlterhelés (overloadiny) 

Számos - főként erősen típusos nyelvekben - létezik ez 

a fogalom. Ez nem is annyira az objektumokhoz kötődik, 
hanem úgy általánosságban létezik, ám most az öröklődés 
és a felülírás kapcsán érdemes néhány szót ejteni róla a fél- 
reértések elkerülése végett. 

A függvénytúlterhelés azt jelenti, hogy több ugyanolyan ne- 
vű, de más paramétereket fogadó (esetleg más visszatérési 
típussal rendelkező) függvényt is definiálhatunk, s a meghí- 
vás során az a függvény hajtódik végre, melynek paraméte- 
rei (száma, típusa) illeszkednek a hívó paraméterekre. Ezzel 
lehet megoldani, hogy egy hasonló funkciójú függvényt 
különböző típusú és számú esetben is alkalmazni lehessen. 
A PHP-ben ez mindkét okból szükségtelen. Mint tudjuk 

a PHP egy gyengén típusos nyelv, egy változó (paraméter) 
értéke lehet egész, lebegőpontos, karaktersorozat, tömb, 
akármi. Így tehát mindegy, hogy az adott paraméter gya- 
nánt milyen típust adunk át. 

A másik ok a paraméterek száma volt. Ez a lehetőség azért 
válik feleslegessé, mivel megadhatunk függvényparaméter- 
ként alapértelmezett értékeket a meghatározásban. A PHP 
tudja, hogy ha a meghívás során nem adunk át paramétert, 
akkor behelyettesíti a definícióban megadott alapértelme- 
zett értéket. 

Ennek folyományaként a PHP-ben sehol sem engedélyezett 
a függvénytúlterhelés, ne is keressük. 
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Tagfüggvény felülírásának megakadályozása 

Számos esetben előfordulhat, hogy ki szeretnénk kötni né- 
hány metódus számára, hogy azokat az örökösök bizony ne 
írhassák felül, ne változtathassák meg az algoritmust. Erre 
olyankor lehet szükség, ha több programozó által használt 
ősosztályt készítünk, és szeretnénk, ha a mi szabályaink 
szerint kódolnának - mert az úgy egységes, ellenőrizhető, 
konzisztens, és így tovább. 

A problémára a final módosító kínál megoldást, amelyet 
tagfüggvények definíciói előtt használhatunk. 


class ososztaly í 
final public function teszt 1 
echo "ősosztály teszt) metódusa lefutott" ; 


class Gyermekosztaly ( 
public function teszt0 1 
echo "felülírt teszt() metódus lefutott" ; 


Ha ilyet szeretnénk csinálni, programunk futása végzetes 
hibával megszakad. 


Elvont osztályok 

Az eddigiekben tárgyalt objektumaink, még ha rokonságba 
is állíthatók egymással, meglehetősen szétszórt szerkezetet 
alkothatnak, s ennek csakis a programozó szabhat határt. 
Mint tudjuk, ez messze nem elégséges feltétel. Sokszor szük- 
ség lenne arra, hogy egy jól átgondolt hierarchiát építsünk, 

s a fejlesztés során, mint karácsonyfáról a szaloncukrot, csak 
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leakasszunk egyet a megfelelő helyről. Ezen szabályozott 
öröklés, hierarchia felépítését segítik az elvont osztályok és 

a felületek, nézzük most ez előbbit. 

PHP 5-ben lehetőségünk van elvonatkoztatott osztályok, 
elvont tagfüggvények létrehozására. Ezek általában olyan 
tagfüggvények, amelyeket az adott osztály nem tud megva- 
lósítani, mondjuk mert nem ismeri a megoldás mikéntjét, 
de azt pontosan tudja, hogy ilyen szolgáltatásra szükség 
lesz majd valamikor, és azt is tudja, hogy a gyermekosztály- 
ok már képesek lesznek a függvény megvalósítására. 

Az absztrakt osztályoknak tehát csak a definíciója ismert, 
nincs is lehetőségünk a konkrét algoritmus megvalósítására 
az adott osztályon belül. 

Az az osztály, amely majd megvalósítja az absztrakt metó- 
dust, legfeljebb olyan erős láthatósági paraméterrel rendel- 
kezhet, mint maga az absztrakt metódus. Ha tehát ez a bizo- 
nyos elvont tagfüggvény protected besorolású, a megvalósí- 
tó gyermekosztályban csak protected, vagy public lehet, 
private nem. Ennek az az oka, hogy az elvonatkoztatott osz- 
tályt készítő programozónak valószínűleg jó oka volt arra, 
hogy az adott láthatósági paramétert választotta, s ha ezt szű- 
kítenénk az öröklés során, a további öröklések folyamán meg- 
változna a tagfüggvény jellege — esetleg teljesen el is tűnne. 
Fontos megjegyezni, hogy ha egy osztálynak van legalább 
egy elvont tagfüggvénye, akkor az osztálynak is elvontnak 
kell lennie, továbbá az ilyen osztályok nem példányosítha- 
tók, csak a gyermekosztályaik. 

Az érthetőség kedvéért íme egy összetett példa: A geomet- 
riánál maradva szeretnénk objektumokkal modellezni 

a szabályos sokszögeket, s elég egyértelmű, hogy a valóság- 
ban ezek egy igen egyszerű hierarchiába szervezhetők, pró- 
báljuk ki a programunkban megalkotott világunkban is 

— az eddigi példáktól teljesen függetlenül! 


abstract class SzabalyosSokszog í 
protected oldalakSzama — 0; 
protected oldalHossz — 0; 


public function 
ss — construct($oldalHossz, $oldalakSzama) ( 
$this-soldalHossztBeallit($oldalHossz) ; 
$this-soldalakszamatBeal lit($oldalakSzama) ; 


public function oldalHossztBeallit($oldalHossz) 
stg 
$this-soldalHossz -$oldalHossz; 


public function oldalakszamatBeal lit 
sz ($oldalakSzama) ( 
$this-soldalakszama-$oldalakSzama; 


public function oldalakaáltalBezartszogÓ í( 
return 360/$this-soldalakSzama; 


abstract public function teruletO ; 
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class NegySzog extends SzabalyosSokszog í 
public function . construct($oldalHossz) ( 
parent::  construct($oldalHossz,4); 


public function terulet() ( 
return $this-soldalHossz"$thi1s-soldalHossz; 


class HatSzog extends SzabalyosSokszog ( 
public function . construct($oldalHossz) ( 
parent::  construct($oldalHossz, 6); 


public function terulet() ( 
return 3"$this-soldalHossz"$this-5 
s oldalHossz"sin(60); 


Kicsit hosszúra sikeredet, de mint látszik, annál egysze- 
rűbb. Íme a szabalyossokszog osztályunk. Jól látható, 
hogy vannak olyan szolgáltatások, amelyek minden gyer- 
mekre ugyanúgy vonatkoznak. Ezek az oldalhossz beállí- 
tása, oldalak számának beállítása, oldalak által bezárt szög 
kiszámítása. Ez minden sokszög esetében ugyanaz. 

De ott van a terület, melynek kiszámítási módját az alap- 
osztály nem ismeri, de tud róla, hogy minden szabályos 
sokszögnek van területe. Ekkor ezt megjelöli, de nem 
valósítja meg. 


Felületek 

A fenti elvont osztályos példa remek akkor, ha olyan tag- 
függvényeket szeretnénk készíteni, amit nem feltétlenül kö- 
telező minden örökösnek megvalósítani. Felmerülhet a kér- 
dés, hogy ezeken a gyermekosztályokon valamilyen közös 
műveleteket végezzünk, mondjuk mindnek kiszámítsuk 

a területét. Ilyenkor elengedhetetlen az, hogy minden gyer- 
mekosztály rendelkezzen a terulet) tagfüggvénnyel, 
különben programhibával le fog állni a futás. A megoldás 

a felületek alkalmazása. 

A felületek olyan osztálydefiníciók, amelyek tartalmazzák, 
hogy az őket megvalósító osztályoknak pontosan milyen 
tagfüggvényeket kell megvalósítaniuk. Hasonló a függ- 
vénydefinícióhoz, csak ez az osztályokra vonatkozik. A fe- 
lületek az absztrakt osztályokkal ellentétben nem tartalmaz- 
hatnak semmilyen megvalósítást, csak az osztály minimális 
,tervét". Nem tiltott, hogy a megvalósító osztály az előírtnál 
több tagfüggvényt tartalmazzon, ám ha nem készít el min- 
den megadott metódust, a program végzetes hibával leáll. 
Egy ilyen felület minden metódusa nyilvános (public) kell 
legyen - ez a felületek természetéből adódik. 

Felületeket tényleg csak akkor használjunk, ha minden 
egyes metódusra szükségünk van. Így az osztályaink egy- 
másnak megfelelők (compatible) lesznek. Sok esetben 
nincs szükség az ilyesmire, azon esetekben inkább az elvont 
osztályokat használjuk. Nézzünk egy példát ismét 

a SzabalyosSokszog osztálytól függetlenül. 


interface SikidomTtulajdonsagok ( 
public function terulet ; 
public function keruletŐ ; 
public function oldalakSzamal ; 
public function tengelyesenSzimmetrikus  ; 
public function kozeppontosanSzimmetrikus O ; 


class Teglalap implements Sikidomrulajdonsagok ( 
//implementálni kell minden tagfüggvényt, de 
//ezen túl készíthetünk konstruktort, oldalbe- 
//állítót,stb. Az a későbbi feldolgozást 
// nem érinti 


Előfordulhat, hogy több felületnek is meg kell felelnünk, 
ekkor az impements kulcsszó után vesszővel elválasztva kell 
megadni az egyes felületek nevét, amit megvalósítunk. 

A felületek megvalósítása természetesen nem zárja ki azt, 
hogy az osztályunk örököljön is. 

Módosítsuk a SzabalyosSokszog példánkat úgy, hogy köte- 
lező legyen a terulet tagfüggvény használata. 


interface Teruletes í 
public function teruletO ; 


abstract class SzabalyosSokszog implements 
s Teruletes í 
protected oldalakSzama — 0; 
protected oldalHossz -— 0; 
public function . construct 
sz ($oldalHossz , $oldalakSzama) ( 
$this-soldalHossztBeallit($oldalHossz) ; 
$this-soldalakszamatBeal lit($oldalakSzama) ; 


public function oldalHossztBeal lit 
s ($oldalHossz) ( 
$this-soldalHossz -$oldalHossz; 


public function oldalakszamatBeal lit 
sz ($oldalakSzama) ( 
$this-soldalakszama-$oldalakSszama; 


public function oldalakaáltalBezartszogOÓ ( 
return 360/$this-soldalakSzama; 


Ekkor a gyermekosztályokhoz nem is kell hozzányúlni, 

de minden későbbit úgy kell elkészíteni hogy tartalmazz 

a teruletO tagfüggvényt. Felmerülhet a kérdés, hogy miért 
nem jelez hibát a PHP a fenti esetben, holott az osztályban 
nem is valósítottuk meg azt a bizonyos terulet) metódust. 
Ennek az az oka, hogy ez egy elvont osztály, tehát nem pél- 
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dányosodhat, ennek értelmében biztosan nem fogja megsér- 
teni a szabályt. Megsértik viszont azok az örökösök, akik el- 
mulasztják eme tagfüggvény megvalósítását. Jelen esetben te- 
hát csak ennyi szerepe van osztályunk elvont voltának, mert 
mint láthatjuk, nem tartalmaz egyetlen elvont metódust sem. 
Az is egy megoldás lett volna továbbá, ha a szülőt változat- 
lanul hagyjuk és a gyermekosztályoknál az öröklés után 
megmondjuk, hogy ezek a Teruletes nevű felületet való- 
sítják meg. (A megoldás hátránya többek között az, hogy 
így minden sokszögfajtára le kell ellenőriznünk a használat 
során, hogy implementálják-e a várt felületeket) 

A gyakorlatban remekül lehet kombinálni az öröklést a felü- 
leteket és az elvont osztályok alkalmazását. Sok esetben ve- 
zet igen-igen érdekes eredményre. Ha jobban megnézzük, 
a fenti esetben is ezt alkalmazzuk. lermészetesen a sok osz- 
tálynak, melyek ugyanazt a felületet valósítják meg, nem 
kell feltétlenül egy helyről öröklődniük, lehetnek teljesen 
függetlenek, látni fogjuk később, hogy lehetőségünk van el- 
lenőrizni egy osztályról, objektumról, hogy megvalósítja-e 
a szerintünk szükséges felületet, felületeket. 


Néhány mágikus tagfüggvény 

Az összes ilyen különleges metódusnak közös tulajdonsága, 
hogy ezeket nem mi, programozók hívjuk, hanem a PHP. 
Hogy tiszta legyen a kép: ide tartoznak a konstruktorok és 
destruktorok, ám azok ismertetése elengedhetetlen volt az 
alapvetésnél. Mosta. set, getO ésa callO tag- 
függvényeket vizsgáljuk meg közelebbről. Megjegyezném, 
hogy a PHP 5 ezen kívül is tartalmaz még olyan függvé- 
nyeket, amelyek -relkezdődnek (ilyen előtag azonosítja 
ugyanis a különleges tagfüggvényeket), ám ezek tárgyalása 
a szűkös terjedelmi keretek miatt most elmarad. 


A — set() tagfüggvény 

Ha egy osztály, objektum tartalmazza ezt a metódust, akkor 
minden olyan esetben lefut, ha mi az adott objektum nem 
létező tulajdonságának adunk értéket. Ez olyankor lehet 
hasznos, ha egy dinamikusan bővülő adathalmaz alkotja 
osztályunk tulajdonságait. Példaképp, ha a program futása 
során különböző gyümölcsök színét szeretnénk összegyűj- 
teni. Célszerű ilyenkor a gyümölcsöket nem külön-külön 
felvenni, mint osztálytulajdonságot, hiszen az fix, ehelyett 
jó lenne dinamikusan bővíteni. Mivel azért a nyelv nem te- 
szi lehetővé, hogy futásidőben ily módon piszkáljuk az osz- 
tályokat, osztálytulajdonság gyanánt használjunk struktú- 
rát, asszociatív tömböt a megoldásra. Ez kellően rugalmas. 
Az esetleges beállító tagfüggvényekkel ugyanez a helyzet: 
nem elég rugalmasak. Itt jön aképbea  setŐ metódus, 
nézzük, hogyan: 


ca?php 
class Gyumolcsok 
private $gyumolcsok - arrayO; 


public function . set($name, $value) ( 
$this-sgyumolcsok[$name]-$value 


J 


$deliGyumolcsok - new GyumolcsokO ; 
$del iGyumolcsok-:snarancs-"sarga" ; 
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$del 1Gyumol csok-scitrom-"citromsarga" ; 
$deliGyumolcsok-sbanan-"erdekesen sarga" ; 
?: 


A  set0O tagfüggvény első paramétere a változó neve 
(ami a -3 után szerepel), a második paraméter pedig az 
érték, ami az egyenlőségjel után szerepel. 

A feladat, tehát megoldva. Bármilyen gyümölcsöt beletehe- 
tünk, kötöttségek nélkül, az érték nem fog elveszni. Vigyáz- 
nunk kell azonban, hogy semmilyen gyümölcsnév ne szere- 
peljen osztálytulajdonságként, mert ha teszem azt van 
$narancs nevű osztályváltozó, akkor a második hívás annak 
értékére fog vonatkozni, nemfutlea  set() metódus. 


A — get() metódusa 

Ha már van egy ilyen szabadon feltölthető osztályunk, 
nem ártana, ha legalább ilyen szabadon hozzáférhetnénk. 
A. set0 párja, a get0O siet ilyenkor a segítségünkre. 
Teljesen analóg módon: ez akkor fut le, ha olyan változó ér- 
tékére vagyunk kíváncsiak, amely nem szerepel az osztály- 


tulajdonságok között. A fentiek ismeretében bővítsük to- 
vább az osztályunkat. 


c?php 
class Gyumolcsok 
private $gyumolcsok - arrayO; 


public function . set($name, $value) ( 
$this-sgyumolcsok[$name]-$value 


public function , get($name) ( 
if (array key exists($name , 
ss $this-sgyumolcsok)) 
return $this-sgyumolcsokl$namel ; 
else 
echo "Nincs ilyen gyümölcs!" ; 


J 

$deliGyumolcsok - new GyumolcsokO ; 
$del iGyumol csok-snarancs-"sarga" ; 

$de ] iGyumol csok-:scitrom-"citromsarga" ; 
echo $deliGyumolcsok-snarancs; 

echo $deliGyumolcsok-sbanan; 

?: 


A példa az első esetben kiírja, hogy sárga, a második eset- 
ben, hogy Nincs i lyen gyümölcs. A megoldás egyértelmű: 
a  get0 paramétere tartalmazza, hogy milyen változóra 

hivatkoztunk. Megnézzük, hogy létezik-e az adott kulccsal 
érték a tömbben. Ha igen, akkor visszaadjuk azt, különben 
kiírjuk, hogy nincs olyan. 


A — call() metódus 

Ez a tagfüggvény is illeszkedik az előző kettőre, ám ez ak- 
kor fut le, ha olyan tagfüggvényt hívunk meg az objektu- 
munk esetében, amely nem létezik. Az előző kettő esetben 
a program semmilyen hibát nemírki,a getO ill. 

.- setO metódusok hiányában sem, ha olyan változóra hi- 
vatkozunk, ami nem létezik. A tagfüggvények hívása esetén 
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ez nincs így, ezért még akár hibaelnyelés céljából is hasznos 
lehet. A metódusnak két paramétere van. Az első a meghí- 
vott tagfüggvény neve, a második pedig a híváskor átadott 
paraméterek tömbje. Ennek segítségével bizonyos híváso- 
kat elkaphatunk, s különböző műveleteket végezhetünk, 
mielőtt visszatérnénk. (A visszatérési érték természetesen 
ugyanúgy viselkedik, mintha valóban létezne az a metó- 
dus). A cél itt is az volt, hogy az objektumok futás idejű 
dinamikus viselkedését növeljék. 


Égy kakukktojás — az automatikus hetöltés 

Bár nem kapcsolódik szorosan az objektumközpontú 
viselkedésmódhoz, de mindenképp hasznos és érdekes 
móka az egyes osztályok igény szerinti betöltésének 
lehetősége. 

A PHP számára eddig is előnynek számított, hogy 

maga a forráskód futásidőben alakítható volt az include, 
reguire parancsokkal - ha például feltételhez kötöttük 
őket. Így ugyanis elérhettük, hogy mindig csak a minimá- 
lisan szükséges méretű kódot kellett a PHP-nak értelmez- 
nie, lefordítania, amivel jelentős sebességnövekedést 
eredményezett. 

Az osztályokat gyakorta helyezzük el külön-külön fájlok- 
ban, ami átláthatóvá teszi kódunkat, ám elég kényelmetlen, 
hogy minden egyes példányosítás előtt be kell töltenünk 
az adott fájlt. Erre nyújthat megoldástaz  autoloadO 
nevű különleges függvény, amely minden olyan esetben 
meghívódik, ha nem definiált osztályt szeretnénk használ- 
ni, példányosítani. A függvény meghívása után a PHP 

még egyszer megpróbálja használni azt a bizonyos osztályt, 
s ha ekkor sem sikerül, hibaüzenettel leáll. A gyakorlatban 
mindez így nézhet ki: 


ca?php 
function . autoload($className) ( 
include once($className. ?" .php" ) ; 


T 


$obj - new ProbaosztalyO ; 
$obj2 - new MasikProbaosztalyO ; 
? 


Ez természetesen nem az egyetlen felhasználási mód, egész 
sor automatikát vihetünk általa programunkba. 


Végszó 

Nos, még mindig nem értünk a téma végére, de már 
közel járunk. Hátra van még a nagy újításnak számító 
Refleciton API, amely az objektumok, osztályok részletes 
elemzésére szolgál, de nem beszéltünk még a típus elő- 
írásról (type hinting), a kivételkezelésről és az objektumok 
másolásáról sem. A cikksorozat következő részében ezekre 
lehet tehát számítani. 


Komáromi Zoltán 
(komiCokiskapu.hu) 

23 éves, a BME hallgatója, mellette 
PHP-programozóként dolgozik. 
Kedvenc területe a multimédia. 





Hálózatok (13. rész) 


Nagy sebességű és múholdas hálózatok, 


hálózati réteg 


Nem szóltam még a nagy sebességű LAN-okról és a műholdas hálózatokról. 
Ebben a részben pótolom ezt, majd belekezdek a következő nagyobb témakörbe, 
a hálózati réteg feladatainak ismertetésébe. 


bben a részben befejezzük az adatkapcsolati rétegről 
történő értekezést, és rátérünk a következő nagy té- 
makörünk, a hálózati réteg bemutatására. Mielőtt 
azonban ezt megtenném, törlesztem két adósságomat: 
szólok pár szót a 10 MbSs feletti sebességű LAN-okról 

és a műholdas hálózatokról. 





Gyors Ethernet 

Eddig többnyire olyan LAN-okkal foglalkoztunk, amelyek- 
nek a lelke egyetlen rézvezeték volt. Erre a rézvezetékre 
kapcsolódtak az állomások, akik állandóan versenyre keltek 
egymással a csatorna használati jogáért. Amíg az állomások 
közötti távolság kicsi, és a felhasználók nem álmodoznak 
nagyobb átviteli sebességről, addig az ilyen hálózatok min- 
den igényt kielégítenek. Ha azonban felmerülnek ehhez ha- 
sonló óhajok, akkor vagy lecseréljük a rézvezetéket üvegszá- 
las kábelekre, vagy több egymással párhuzamos rézvezeté- 
ket létesítünk az állomások között. A 90-es évek elején fel- 
merült tehát az igény egy új gyorsabb hálózati szabvány ki- 
fejlesztésére, így az IEEE fel is kérte erre a 802.3 bizottságot. 
Két koncepció látott napvilágot. Egyesek úgy tartották, 
hogy el kellene vetni teljes egészében a 802.3-as szabványt, 
és egy teljesen elölről kezdeni mindent, vadonatúj proto- 
kollokkal és szolgáltatásokkal (például digitális hangátvitel). 
Mások úgy gondolták, hogy fontosabb, ha az új szabvány 
kompatibilis marad a 802.3 szabvánnyal, a különbség csak 
a sebességben mutatkozna. Ez a két egymástól homloke- 
gyenest eltérő meggondolás remek alapot szolgáltatott 
éjszakába nyúló vitákhoz. A bizottság végül az utóbbi elv 
(a kompatibilitás megtartása) mellett voksolt, amelybe 

a másik tábor nem tudott beletörődni, így létrehozták 

saját szabványukat (amely a 802.12 alapja lett). 

Valóban nehéz kérdés, hogy a kettő közül melyik elgondo- 
lás a célravezetőbb, hiszen az Ethernet-el is sok probléma 
van (erről már részletesen beszámoltam egy régebbi epi- 
zódban), viszont a már meglévő több ezer (esetleg millió?) 
hálózat miatt fontos a kompatibilitás, arról nem is beszélve, 
hogy az Ethernet már egy jól működő dolog volt. Az újabb 
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protokollok és szabványok bevezetése mindig magukban 
rejthetnek olyan problémákat, amelyekre a tervezés során 
senki sem gondolt. 

1995 júliusában létrejött tehát az új IEEE szabvány, amely 

a 802.3u kódnevet kapta, de leginkább gyors Ethernet (fast 
Ethernet) néven híresült el. Mivel ennek hátrafelé kompati- 
bilisnek kellett maradnia, ezért nem volt szabad az interfé- 
szeket, illetve a kerettormátumokat megváltoztatni. A bit- 
időt azonban csökkenteni lehetett a tizedrészére, így elvileg 
tízszer nagyobb sebesség érhető el. 

A gyors Ethernet kábelezése viszont nem engedi meg 

a 10Base-5, illetve a 10Base-2 által használt kábelezéseket. 
Nem használhatunk tehát BNC és vámpír csatlakozókat. 

A 10Base-T kábelezését azonban szimpatikusnak találták, 
így erre alapoztak. Ha visszaemlékszünk, ez az a kábele- 
zés, ahol csavart érpárokat is elosztókat (hub) haszná- 

lunk. Az ilyen gyors Ethernet hálózatokat 100Base-T-nek 
nevezzük. 

Lehetőség kínálkozik arra is, hogy csavart érpárok helyett 
üvegszálas kábeleket használjunk (100Base-FX). Ilyenkor 

a hub-tól az állomáshoz két, ellentétes irányú üvegszálas 
kábelt helyezünk el, ezzel biztosítva van a duplex üzem- 
mód. Az üvegszálas kábelek egyik nagy előnye, hogy az 
állomás és az elosztó közötti távolság jóval nagyobb 

(akár 2 km) lehet, mint a csavart érpár esetén (200 méter). 
Az ilyen hálózatok kiépítése költséges, hiszen az olyan 
elosztók, amelyek nagyobb számú porttal rendelkeznek, 
elég borsos árúak. Mindezek ellenére megéri a beruházás, 
hiszen nem kell tartanunk az ütközésekről, az összes állo- 
más bármikor adhat, illetve vehet. Ez a tény már önmagá- 
ban több nagyságrenddel nagyobb sávszélességet ered- 
ményez. Szintén megdobja a költségeket az is, hogy az 
állomások hálózati csatolójának is támogatnia kell a gyors 
Ethernet szabványt. 


Műholdak 


Sokféle adatszórásos hálózattal foglalkoztunk már, a műhol- 
das rendszerekre azonban még nem tértünk ki részletesen. 
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1. ábra Geostacionárius pályák 


] Allalmazásiréteg T 


Átviteliréteg — ] 


Hálózatiíréteg  Í 


Adatkapcsolati réteg 


OSI verem TCPAP verem 





2. ábra Az OSI és a TCP/IP verem rétegei 


Manapság pedig nagyon nehéz lenne az élet műholdak 
nélkül, amelyek fontos szerepet töltenek be a hírközlés- 
ben és az adatátvitelben. De vajon pontosan mi is a fel- 
adatuk, miként is működnek, és milyen típusai repked- 
nek a fejünk felett? 

Távközlési szempontból az a legnagyobb baj a Földdel, 
hogy gömbölyű. Ezért például rádióhullámok segítségé- 
vel nem lehet két egymástól nagyon távol elhelyezkedő 
ponttal kapcsolatot kiépíteni. Persze átjátszó állomások 
segítségével megoldható a probléma, csak hát ezeket 
meg kell építeni, karban kell tartani, és fohászkodni, 
hogy ne sérüljön meg például valamilyen természeti 
katasztrófa következtében. 

Másik megoldás, hogy keresünk egy égitestet, amely vissza- 
veri az általunk küldött elektromágneses jeleket. Ilyen pél- 
dául a Hold. Az 50-es években folytak is kísérletek egy 
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olyan navigációs rendszer kifejlesztésére, amelynek alapja 
a Hold által visszavert elektromágneses hullámok érzékelé- 
se volt. A Hold azonban nem képes a visszavert jelek felerő- 
sítésére. Nem úgy mint a távközlési műholdak, amelyeknek 
ez a legfontosabb feladatuk. 

A műholdakat legkönnyebben keringésük pályája szerint 
csoportosíthatjuk. Az 1. ábrán láthatunk pár kitüntetett 
keringési pályát. Kékkel jelöltük az úgynevezett geostaci- 
onárius pályát, amelynek síkja egybe esik az Egyenlítőé- 
vel. Ha az egyenlítő felett 35792 km-es magasságban he- 
lyezünk el műholdakat, akkor azok keringési ideje meg 
fog egyezni a Föld tengely körüli forgásának idejével, 
amely majdnem 24 óra. Ez azt jelenti, hogy a Föld felszí- 
néről nézve a műhold az égbolton egy helyben áll. (Persze 
ez csak látszólagos nyugalom, a műhold valójában 3064 
km/s-os sebességgel száguld). 

A pálya ezen tulajdonságát leginkább a televíziós műsor- 
szórással megbízott műholdak tudják kihasználni. A Föl- 
dön a IV előtt bambuló felhasználóknak sincs más dol- 
guk, minthogy egyszer irányba állítani antennájukat. 

Egy ilyen műhold a Föld felszínének körülbelül 3870-át 
képes besugározni, így könnyedén kiszámíthatjuk, hogy 
három darab műholdat tartalmazó hálózattal az egész 
bolygót lefedhetjük. 

Az úgynevezett egyenes vagy direkt műholdpályák az 
egyenlítő síkjával 0 — 90 fokot zárnak be. Ezen többnyire 
navigációs, felderítő műholdak közlekednek, többnyire ala- 
csonyabb röppályán. A napszinkron pálya esetében a pálya 
síkja és a Nap iránya által bezárt szög minden esetben ál- 
landó. Ez azt jelenti, hogy itt a műholdak , együtt járnak 

a nappal", azaz egy adott pont fölé mindig ugyanabban 

az időpontban ér. 

Nem minden műhold lakik olyan magasan, mint 

a geostacionárius műholdak. Manapság egyre nagyobb 
szerep jut az úgynevezett alacsony röppályás műholdak- 
nak is. Ezekkel a műholdakkal az a gond, hogy csak kevés 
ideig vannak látótávolságban. Ezt a hátrányt úgy akarták 
orvosolni, hogy amint hatótávolságon kívülre ér az egyik 
műhold, egy másik pont akkor lép be. Ez volt az alapja az 
Iridium nevű projektnek is. Itt eredetileg 77 (végül már 
csak 66) darab műholdat szerettek volna 750 km-es magas- 
ságba állítani abból a célból, hogy egy olyan világméretű 
hálózatot alakítsanak ki, amelyek kézi eszközök között 
teremtene kapcsolatot. Sajnos a projekt nem hozta meg 

a várt sikert, valószínűleg a magas percdíjak és a GSM 
hálózat elterjedése miatt. 


Csatornakiosztás műholdas hálózatok esetén 

A műholdas hálózatok az egyetlen olyan WAN-ok, ame- 
lyek a LAN-okhoz hasonlóan osztott csatornát használ- 
nak. A földi állomások a műholddal az úgynevezett felfelé 
irányuló (uplink) frekvencián küldenek kereteket a mű- 
hold felé. A műhold feladata a hub-okéhoz hasonló: min- 
dent meg kell ismételniük, amit hallanak. Így a beékezett 
jelet felerősítve szétszórják a lefelé irányuló (downlink) 
frekvencián. Fontos, hogy az uplink és downlink frekven- 
ciák különbözőek, így nem zavarják egymást a beérkező 
és a kimenő hullámok. Mivel a downlink frekvencián csak 
a műhold beszél, ezért versenyhelyzet csak a felfelé irá- 
nyuló csatornán alakulhat ki. 


et 


A kérdés már csak az, hogy miként oszthatjuk fel a kö- 
zös csatornát az állomások között. Most kicsit más 

a helyzet mint a LAN-ok esetében, ugyanis a távolsá- 
gok jóval nagyobbak. Igaz, hogy a jelek fénysebességgel 
terjednek, de a műholdak olyan messze vannak, hogy 
még így is számolnunk kell az átlagosan 270 ms-os jelter- 
jedési idővel. Ez pedig azzal a sajnálatos következ- 
ménnyel jár, hogy nem megoldható a vivőjel érzékelés 
(azaz nem tudjuk megállapítani, hogy ad-e éppen vala- 
ki rajtunk kívül). Ha egy állomás belehallgat a lefelé irá- 
nyuló csatornába, akkor csak azt tudja meg, hogy 270 ms- 
al ezelőtt valaki adott, amely a számítógépek számára 

a távoli múlt. Arra esély sincs, hogy megtudjuk, mi 
történik a jelenben. 

Problémánkra a legegyszerűbb megoldás a lekérdezés 
(polling). Amikor egy közös csatornát meg akarunk osztani 
több állomással, akkor azt úgy is megtehetjük, hogy körbe 
kérdezünk mindenkit, van-e épp elküldendő adata. A mű- 
hold persze ezt nem teheti meg, mivel a 270 ms-os jelterje- 
dési idő miatt rendkívül nagy késleltetési idővel kéne szá- 
molni. Ha az állomásokat azonban össze tudjuk kötni egy 
kis sávszélességű földi hálózattal, akkor logikai gyűrűbe 
szervezhetjük őket. Innentől kezdve csak az adhat, akinél 
a vezérjel van. Kis állandó számú állomások esetén ez egy 
hatékony módszer lehet. 

Műholdak esetében is használható a már régebben bemuta- 
tott réselt ALOHA, EDM és IDM csatornaosztásos módsze- 
rek. Mi most helyhiányra hivatkozva csak a TDM-et mutat- 
juk be műholdas környezetben. 


Latogasson el hozzánk! 


A TDM esetében meg van határozva pontosan, hogy me- 
lyik állomás mikor adhat. Ehhez fel kell osztanunk egy idő- 
intervallumot egyenlő részekre, úgynevezett időrésekre. 
Minden időrést hozzárendelünk egy-egy állomáshoz. 

Az állomások csak akkor adhatnak, amikor éppen a saját 
időrésükben vannak. Ehhez élből két problémát is meg kell 
oldanunk: egyrészt egyeztetni kell az állomások óráját, hi- 
szen mindenkinek tudnia kell, hogy mikor kezdődik a saját 
időrése. Másrészt az időréseket el kell tudnunk osztani az 
állomások között. 

Fi ézzük először az 2.6lső Problémát É állomások SZÍTTKGOKS 
földi állomás, a referenciaállomás szabályos időközöne 

ként egy jelet bocsát a műhold felé, amely szétszórja azt 

az állomások között. Ez lesz az úgynevezett óraindító jel, 
ehhez képest fogják kiszámolni az időrések kezdetét. 

Ha például egy időrés T időpillanatig tart, akkor az n-edik 
időrés kezdete az óraindító jeltől számított k"T idő múlva 
következik be. 

Az időréseket ki lehet osztani statikusan és dinamikusan. 
Kis állandó számú állomások esetén megfelelő az első mód- 
szer, de ezt az esetet leszámítva mindig a dinamikus kiosz- 
tás a célravezető. Erre több módszer is kínálkozik. 

Az első módszer él azzal a feltételezéssel, hogy legalább 
annyi időrés van, mint állomás. Ez azt jelenti, hogy minden 
állomás rendelkezik egy , saját bejáratú" időréssel. Ha egy 
állomás ki van kapcsolva, vagy nincs küldendő adata, akkor 
az időrése kihasználatlanul marad. Erről tudomást szerez 

a többi állomás (a lefelé irányuló csatorna figyelésével), így 
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Virtuális könyvesboltunk egyedülálló választékot kínál 
magyar és angol nyelvű számítástechnikai könyvekből. 
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legközelebb az állomások versenyezhetnek ezért az időré- 
sért. Ha az időrés tulajdonosának mondanivalója akad, és 
vissza szeretné szerezni saját időrését, akkor nem kell mást 
tennie, mint egy keretet elküldenie. Ilyenkor ütközés követ- 
kezik be, ami után (a tulajdonost kivéve) egyik állomás sem 
fogja használni az adott időrést. Ha megfigyeljük, ez egy 
hatékony módszer abból a szempontból, hogy az állomások 
viszonylag rövid időn belül szóhoz jutnak, viszont alacsony 
csatornakihasználtság esetén nem a legjobb hatásfokot pro- 
dukálja. Nem beszélve arról, hogy csak akkor használható, 
ha előre ismerjük az állomások számát. Ha ismeretlen, sőt 
mi több, változó számú állomásokkal van dolgunk, az idő- 
réseknek nem lehet állandó tulajdonosa. 

A másik módszer erre az esetre kínál megoldást. Az időré- 
sekért az állomások a réselt ALOHA-nál bemutatott mód- 
szerhez hasonlóan versenyeznek. Ha egy állomás sikeresen 
forgalmazott egy keretet (nem történt ütközés), akkor leg- 
közelebb is adhat ugyanabban az időrésben. Ezzel elméleti- 
leg egy állomás bármeddig adhat, amíg csak van elkülden- 
dő adata. A gyakorlatban azonban az állomások figyelnek 
arra, hogy ne adjanak túl sok időrésen keresztül, és máso- 
kat is hagyjanak szóhoz jutni. 


A hálózati réteg 

Befejeztük végre az adatkapcsolati réteg, illetve a közegel- 
érési alréteg tárgyalását. Most egy magasabb szintre lé- 
pünk: a hálózati réteg szintjére. Hasonlóan, ahogy eddig 

is tettük: először megfogalmazzuk, hogy mi is pontosan 

a réteg feladata, illetve milyen problémákra kell megoldást 
nyújtania. Ezek után következik csak a gyakorlati megvaló- 
sítás ismertetése. 

A hálózati réteg feladata a csomagok célbajuttatása. Mivel 

a forrás- és a célállomás gyakran különböző hálózatokban 
van, ezért a csomagoknak akár több útválasztón is át kell 
haladniuk. Láthatjuk, hogy ez a feladat mennyire elkülönül 
az adatkapcsolati réteg feladatától. Az utóbbi szinten csak 
kereteket kellett továbbítanunk a csatorna egyik végéről 

a másikra. Az adatkapcsolati réteg tehát két szomszédos, 
vagy legalábbis azonos csatornát használó állomások között 
valósította meg az átvitelt. A hálózati réteg viszont két tet- 
szőleges végpont között teremt kapcsolatot. Eddig nem volt 
olyan rétegünk, amely erre képes lett volna, tehát a hálózati 
réteg a legalacsonyabb olyan szint, ahol a hálózati végpont- 
ok kommunikálhatnak egymással. 

Fontos megérteni, hogy a hálózati réteg nem foglalkozik 
közvetlenül az átvitel megvalósításával, hiszen arra ott 
vannak az adatkapcsolati réteg szolgálatai. Két útválasztó 
(router) között az átvitel általában pont-pont kapcsolattal 
van megvalósítva, amelynek kezelését az adatkapcsolati 
réteg végzi. A hálózati réteg igazi feladata a csomag útba- 
igazítása. Mivel a hálózati réteg ismeri a kommunikációs 
alhálózat (a routerek hálózatának) felépítését, ezért csak 
ő tudja, hogy a forrástól milyen útvonalon juthat el a cso- 
mag a célhoz. Ráadásul mindezt úgy kell megvalósítania, 
hogy elkerülje egyes útválasztók terheltségét, a torlódá- 
sok kialakulását. A forgalmat a lehető legegyenletesebben 
kell elosztania. 

A hálózati réteg a szállítási réteg (transport layer) számára kí- 
nál szolgálatokat. Ugyanúgy, mint a többi már ismertetett ré- 
teg esetében, a hálózati rétegnek el kell rejtenie a megvalósí- 
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tás kérdéseit. A szállítási réteget nem fogja érdekelni 

a kommunikációban résztvevő alhálózatok száma, topológiá- 
ja, típusa. A szolgálatoknak függetlennek kell lennie az 
alhálózatok felépítésétől. A szállítási réteg mindig csak egy cí- 
met szeretne mondani, ahová a csomagot szánja. Nem tudja, 
és nem is érdekli, hogy az adott cím fizikailag merre is talál- 
ható. Ehhez persze az is szükségeltetik, hogy legyen egy 

bi felsőbb réteg egyértelműen azonosíthatja a végpontokat, 

a hálózat kiterjedésétől függetlenül (azaz ugyanazt a címzést 
lehessen használni LAN-ok és WAN-ok esetében is). 

Más kikötés nincs előírva a hálózati réteg szolgálatai számá- 
ra. Ez azt jelenti, hogy a hálózatok tervezői viszonylag nagy 
szabadságot kaptak a megvalósításban. Rajtuk áll például 
az is, hogy a hálózati réteg összeköttetés alapú vagy össze- 
köttetés nélküli szolgálatot alakítsanak-e ki. Sorozatunk első 
részében sokat foglalkoztunk e kér szolgálat típus tulajdon- 
ságaival. Ott az összeköttetés alapú szolgálatot a telefon- 
rendszerrel szemléltettük: ahhoz, hogy kommunikálhas- 
sunk valakivel, először fel kell hívnunk őt, azaz fel kell épí- 
teni a kapcsolatot. Miután mindent megbeszéltünk, a kap- 
csolatot végül le kell bontani. Az összeköttetés nélküli szol- 
gálatra a legjobb példa a postai úton történő levelezés. 

Az internet is ezt a megoldást alkalmazza. Ő a hálózati réte- 
get egy egyszerű postásnak tekinti, akinek a feladata kime- 
rül a csomag kézbesítésében. Ezért a felsőbb rétegek fel sem 
tételezhetik azt, hogy a célhoz a csomagok feladásuk sor- 
rendjében, sértetlenül fognak megérkezni, továbbá nem 
várhatnak el olyan bonyolult szolgáltatásokat, mint a forga- 
lomszabályozás. Egyszerűbben úgy fogalmazhatjuk meg, 
hogy a hálózati réteg interfészében két primitív található: 

a csomag küldése és a csomag fogadása primitív. (A primití- 
vek a felsőbb rétegek által meghívható elemi műveletek). 
Nem minden hálózat követi ezt az elvet, az AIZM hálózatok 
például összeköttetés alapúak. Itt akommunikáló két fél 
először felépít egy kapcsolatot, a csomagok sorrendhelye- 
sen érkeznek meg, és még a forgalomszabályozás is biztosít- 
va van, tehát az adó nem adhat gyorsabban, mint ahogy azt 
a vevő fel tudja dolgozni. 

A két szemlélet között az igazi különbség az, hogy a hálóza- 
ti modell mely rétege végezze a nehéz, összetett munkát. 
Az első megközelítésben ezt a szállítási réteg végzi. Ő fogja 
majd a csomagokat sorrendbe helyezni, figyelni a hibákra 
és a forgalomirányításra. Ezt legtöbbször az operációs rend- 
szer szintjén valósítják meg, tehát maguk a gépek (host) 
fogják a munka számításigényes részét átvállalni. A másik 
szemlélet szerint a felhasználókat meg kell kímélni attól, 
hogy saját számítógépeiken futtassanak összetett számításo- 
kat igénylő protokollokat. 

Mindkét megoldásnak megvan a maga előnye és hátránya. 
Erre részletesen kitérünk majd a következő részben, ahol 
foglalkozunk majd a hálózati réteg belső felépítésével, és 
megismerkedünk pár forgalomirányító algoritmussal. 


Garzó András (garzoandXointerware.hu) 

Körülbelül három éve foglalkozik Linux- és más Unix-rendsze- 
rekkel. Legjobban az operációs rendszerek lelkivilága érdekli, 
de nyitott egyéniség. Kedvenc étele a palacsinta, és van egy 
Richard nevű macskája. Minden észrevételt, megjegyzést, 
levelet szívesen fogad. 


Lámpák...Kamera...Tessék! 


Elég egy webkamera, egy mikrofon, néhány nyílt forrású csomag, és máris 


összeáll egyszerű videóstúdiónk. 


ttól tartok, igaz, Francois. A kamera nem hazudik. 
AA Így nézel ki, miközben bort szolgálsz fel. Ó, de- 

hogy, mon ami, eszembe sem jutott, hogy kite- 
gyem a filmet a vendéglő weblapjára. Hogy miért csiná- 
lom? Aaaa...! le még nem láttad a mai ajánlatunkat? Multi- 
média és szórakozás a jelszó, mon ami, és mint magad is lá- 
tod, ez egy roppant szórakoztató kis filmecske. Ne izgasd 
fel magad, Francois, a végsőkig tiéd a tiszteletem. Különben 
is, marakodásra most nincs idő, vendégeink bármelyik pil- 
lanatban itt lehetnek. Már ott is toporognak az ajtóban! 
Üdvözöl benneteket, mes amis, a Chez Marcel! Olyan jó itt 
látni benneteket, a világ legjobb linuxos vendéglőjében, és 
egyben a világ egyik legpompásabb borospincéjében. Foglal- 
jatok helyet, helyezzétek magatok kényelembe. Francois ép- 
pen most indult a pincébe. A 2001-es Santa Lucia Highlands 
Pinot Noizr szinte itatja magát. Rikító borfajta, a sztárok vilá- 
gát idézően sziporkázó - kiválóan illik mai menünkhöz. 
lalán már nektek is feltűnt, hogy manapság minden mun- 
kaállomás fel van szerelve kamerával és mikrofonnal. 
Kézenfekvő ötlet, hogy mi - vagy valamelyik társunk — 
legyünk saját filmünk sztárjai, ám a középpontba ezúttal 
a programok kerülnek. Végül is, a Chez Marcel menüjén 
már nem egy alkalmazás ragyogott fel, non? Itt jön a képbe 
Karl Beckers xvidcap nevű programja. Az xvidcap kiváló kis 
eszköz az X munkaasztalunkon történtek rögzítésére, ami- 
hez csupán az ffmpeg nevű programot használja segítségül, 
ami viszont valószínűleg már fent van a gépünkön. Ered- 
ményként egy MPEG filmet kapunk munkaasztalunk egy 
részéről vagy egészéről. 
Azt kérditek, mire jó ez? Például oktatási célú filmeket ké- 
szíthetünk vele, amelyen megmutathatjuk másoknak, ho- 
gyan használjanak egy-egy alkalmazást, esetleg közhírré te- 
hetjük, milyen jók vagyunk a kedvenc lövöldözős játékunk- 
ban. Az xvidcap beszerzéséhez látogassunk el a hivatalos 
weboldalra. (Lásd a kapcsolódó címeket.) Az oldalról forrás 
és bináris csomagokat is letölthetünk, utóbbiak RPM és 
DEB kiterjesztéssel szerepelnek. Ha saját terjesztésünkhöz 
nincs előre lefordított csomag, akkor az xvidcap fordítását 
a megszokott öt lépést követve végezhetjük el: 





tar -xzvf xvidcap-1.1.3.tar.gz 
cd xvidcap-1.1.3 
. /configure 
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1. ábra A felvételi ablak beállítása xvidcap/gvidcap alatt 


make 
su -c "make install" 


A program neve xvidcap vagy gvidcap. Azért említek két 
nevet, mert ha rendelkezünk a GTIK2- fejlesztői könyvtár- 
ral (2.2.1-es vagy újabb változat), akkor egy második bináris 
fájlt is kapunk. Mindkét példány azonos módon működik, 
de őszintén szólva a GTK2- felület sokkal jobban néz ki. 

A felületet akkor is elérhetjük, ha nincs fent a gépünkön 
valamelyik újabb GTIK2--, de ilyenkor ne a forrást, hanem 
valamelyik bináris csomagot válasszuk. 

A program bármelyik változatát is indítjuk el a parancssor- 
ból, egy egyszerű eszköztárat fogunk látni néhány gomb- 
bal, alatta egy vörös téglalappal. Ez a rögzítési ablak, ezt 
kell a felvenni kívánt területre mozgatnunk. Az alapértel- 
mezett ablak meglehetősen kis méretű. Ha meg szeretnénk 
változtatni a felvétel tárgyát képező területet, kattintsunk 
a célkeresztet ábrázoló ikonra (jobbról a második az eszköz- 
táron), majd kattint és húz módszerrel állítsuk be a kívánt 
területet. A vörös téglalap átméreteződik. Az eszköztáron 
megtaláljuk a felvétel elindításához, leállításához, szünetel- 
tetéséhez stb. szükséges gombokat. Ha kicsit elidézünk 

a gombok felett, megjelennek a vonatkozó tanácsok. 
Ennyi, máris filmre vehetjük a vörös téglalapon belül 
történő eseményeket. (1. ábra) 
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Fogadó a Linuxhoz 


eididtáted 


Modify runtime preferences: 


£] Frames per Second (FPS) 


[tet.mpeg Filename 
[1000 Ej Max. number of Frames 
[0 Fr Max. time to record 


I Autocontinue 


[MPEGa 7] video codec 
99 


KET 1 Image Ouality 


0 
(CT TK Compression 
I Useshared Memory 
CC black 


[7 Capture Mouse Pointer (6. white 


gZ OK XX Cancel 


2. ábra A gvidcap beállító párbeszédpanelje 








A beállítások révén megváltoztathatjuk a másodpercen- 
ként felvett képkockák számát, az alkalmazott mozgókép- 
kodeket, valamint megadhatjuk, hogy az egérmutató szere- 
peljen-e a filmben. Kattintsunk az egér jobb gombjával az 
eszköztár bal szélső gombjára, majd válasszuk a Preferences 
(Beállítások) parancsot. (2. ábra) Ha tettünk már néhány 
próbát, aman xvidcap paranccsal azt is kideríthetjük, ho- 
gyan használhatjuk grafikus felület nélkül a programot. Kü- 
lön érdekesség, hogy a program hangrögzítésre is alkalmas, 
ami különösen oktatási célú filmek készítésekor hasznos. 
Az ffmpeget azért említettem meg már az xvidcap bemutatá- 
sakor is, mert lenyűgözően sokoldalú program, érdemes 
megismerkedni vele. Az ffmpeg segítségével szinte ingyen 
készíthetünk saját filmeket. Elég egy olcsó webkamera, ha 
hangot is akarunk, akkor kell egy egyszerű mikrofon, de 
másra nincs is szükségünk, kivéve persze az ffmpeget. 
Néhány hete felkértek, hogy készítsek egy könyvhöz egy 
bevezető videót. A minőség nem volt szempont, az egész 
egy kísérleti dolog volt, messze nem a végleges megoldás. 
Mivel megfelelő videokamera nem volt kéznél, rögtönöz- 
nöm kellett, és azt hiszem, a világ legolcsóbb videóstúdióját 
sikerült összeállítanom. (3. ábra) A felszerelés egy olcsó mik- 
rofonból és egy szintén alsó polcos, LISB-s, CPIA lapkával 
felszerelt webkamerából állt. Linuxos rendszeremmel fel- 
fegyverkezve bármire készen álltam. A kérdés csak az volt: 
,Hogyan?" 

Az ffmpeg segítségével felvettem a filmet, aztán kísérletez- 
tem egy kicsit az időzítéssel, a képfrissítéssel és a többi beál- 
lítással — végül egész meggyőző eredményt kaptam. Az 
alábbi paranccsal egy AVI formátumú, tíz képkocka/másod- 


st sé 


perc frissítésű filmet vettem fel: 


ffmpeg -vd /dev/video -ad /dev/sound/dsp -r JON 
-s 352x288 video teszt.avi 


Ennyi. A bemeneti videóeszköz (ezt a -vd kapcsoló adja 
meg) a /dev/video, a hangforrás (-ad kapcsoló) pedig 

a /dev/sound/dsp volt. lermészetesen más gépeknél az 
eszközök neve ettől eltérő is lehet. Az egyik másik gépemen 
például az USB-s videóeszköz a /dev/video0. Ha a paran- 
csot ebben a formában adjuk ki, akkor a felvétel egészen 

a merevlemez megteléséig folytatódik. Ha korlátozni akar- 
juk a felvétel hosszát, például 10 másodpercre, akkor a -t 


kapcsolót kell használnunk: 
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3. ábra A világ legolcsóbb videóstúdiója? 


ffmpeg -vd /dev/video -ad /dev/sound/dsp -r ION 
-s 352x288 -t 10 video teszt.avi 


A létrejövő filmet melynek neve video. teszt. avi lesz, 
Xine, Kmplayer, MPlayer vagy egyéb hasonló program 
segítségével játszhatjuk le. 

Nos, mes amis, azt hiszem, sikeresen betörtem a költség- 
hatékony videostúdiók piacára. Amikor elküldtem a felvett 
filmet, megkértek, hogy inkább MPG formátumban adjam 
oda. lermészetesen nem forgattam újra a filmet, inkább az 
alábbi paranccsal átalakítottam a fájlt: 


ffmpeg -i video teszt.avi video teszt.mpg 


Amilyen sokoldalú az ffmpeg, biztosan jó néhány percet el 
tudunk időzni súgóoldalának tanulmányozásával. Ígérem, 
rengeteg érdekes szolgáltatást fogunk felfedezni. 

Azok számára, akik rendelkeznek digitális videokamerával, 
nem okozhat gondot a jó minőségű felvételek elkészítése. 
Ez esetben a kihívást inkább a felvétel számítógépre juttatá- 
sa jelenti, hiszen szerkesztését, tömörítését és másoknak is 
elküldhető lemezre írását leginkább így tudjuk elvégezni. 
Nekem egy Sony Handycam kamerám van. Van rajta USB 
kapu, de támogat egy ennél jóval gyorsabb soros buszt is, 
amit a legtöbben FireWire névvel ismernek. A műszaki té- 
mák iránt fogékonyabbak sokszor IEEE1394-nek hívják. 
Számítógépünk oldalán szintén szükségünk van egy ilyen 
portra vagy csatolókártyára, ami ugyan költséget jelent, ám 
az IEEE1394 busz teljesítménye messze kárpótol ezért. 

Ha a kapott felvételt értelmes módon akarjuk szerkeszteni, 
akkor meg kell kaparintanunk egy megfelelő szerkesztő- 
programot, például Arne Schirmacher Kino-ját. (Lásd a 
kapcsolódó címeket.) A dugrab program, mely szintén 

a Kino weboldaláról érhető el, a Kino része, így ezt nem kell 
külön letöltenünk. Látjátok, mes amis, az xvidcaphez hason- 
lóan a Kino is rejt parancssori eszközöket a csinos felület 
alatt. Ezek egyike jó öreg barátunk, az ffmpeg. 

Mára Arne kiváló fejlesztőket gyűjtött maga köré, akik 
rendkívül csinos, könnyen használható linuxos videoszer- 
kesztő alkalmazást állítottak össze. A Kino egyik szépsége 
abból fakad, hogy az IEEE1394-et támogató videokame- 
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4. ábra Házi felvétel szerkesztése a Kino-val 


ránkról képes közvetlenül átmásolni a szerkesztendő felvé- 
telt. Ha rendelkezünk ilyen FireWire kábelen keresztül csat- 
lakoztatható kamerával, akkor még vezérlését is a Kino-ra 
bízhatjuk. Mielőtt továbblépnénk, hadd ejtsek néhány szót 
az IEEE1394 támogatásáról. Az újabb Linux terjesztésekből 
nem hiányozhat az IEEE1394 - betölthető rendszermag- 
modulok révén megvalósuló -— támogatása, ám például az 
én tesztrendszeremen az illesztőprogramok nem töltődtek 
be önműködően. Sebaj, betöltöttem őket kézzel: 


modprobe ohci1394 
modprobe raw1394 
chmod 666 /dev/raw1394 


A digitális felvétel átmásolása az IEEE1394 kábelen keresztül 
a számítógépre a parancssorból is könnyedén elvégezhető 

a dvgrab-bel. Tulajdonképpen a Kino is ezt a módszert követi. 
Bár a másolást egyszerűen a dvgrab paranccsal is elindíthat- 
juk, inkább használjuk a -i kapcsolót, mely interaktív módba 
állítja a programot. Ezt követően vezérelni tudjuk a kamerát, 
és egyszerű gyombnyomásokkal irányíthatjuk a rögzítést. 


dvgrab -i 

Going interactive. Press "? for help. 

dg-guit, p-play, c-capture, Esc-stop, h-reverse, 

sz J-backward scan, 

k-pause, 1-forward scan, a-rewind, zZ-fast forward, 
550-9-trickplay, 

cspaces-play/pause 

Capture Started 


Igaz, hogy a legtöbben megszoktuk a grafikus felületek 
használatát, de ne féljünk, mindez sokkal egyszerűbb és 
elegánsabb, mint ahogy hangzik. A létrejövő fájl neve 
alapesetben dvgrab-XXX. avi lesz, ahol az xxx három 
számjegyet takar. 

A Kino felhasználói felülete letisztult, könnyen érthető és 
kezelhető. (4. ábra) A főablak jobb oldalán lévő fülekkel ér- 
hetjük el a különféle szolgáltatásokat, kezdve a rögzítéstől, 
a szerkesztésen keresztül egészen a késztermék kiírásáig. 
A munka túlnyomó részét az Edit (Szerkesztés) lapon vé- 
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gezzük el; persze csak a rögzítés után. Itt tudjuk egyesíteni 
és szétvágni a jeleneteket, de további fájlokat is beilleszthe- 
tünk filmtervezetünkbe. A Timeline (Idővonal) fül az éppen 
kiválasztott jelenetet képkockákra bontja, így a film tetsző- 
leges pontjára ugorhatunk úgy, hogy nem kell az egészet 
lejátszanunk. 

Az EX lapon különleges hatásokat adhatunk hozzá a film- 
hez, ilyen például a visszirányú lejátszás, a szépia hatás, 

a tükrözés és a kaleidoszkóp. A hanghatások között elhal- 
kulást, felerősödést és némítást találunk. 

Ha ráéreztünk a digitális videózás ízére, valószínűleg né- 
hány percesnél hosszabb felvételeket is készítünk majd. 
Mindezt azért hozom szóba, mert amikor a Kino-val átmá- 
soljuk a felvételt a számítógépre, több nagyméretű, körülbe- 
lül 820 MB-os fájl is létre fog jönni, ezek tartalmazzák a film 
egyes részeit. Nyilvánvaló, hogy végeredményül nem ilyen 
fájlokat várunk. Pontosan ezért kell megbarátkoznunk az 
Export (Kimentés) lappal. Ezen - allapok egy csoportján — 
különféle lehetőségeket találunk, például külön kimenthet- 
jük WAV fájlokba a hangsávot. Nekem nagyon tetszett az 
egyes képkockák kimentésének lehetősége is. Az utóbbi 
időkben a legtöbbet mégis a DV pipe (DV csővezeték) szolgál- 
tatást használom, ahol az ffmpeg újfent szerephez jut. 
Amikor minden szerkesztéssel és vágással végeztem, az 
ffmpeg segítségével videó CD AVI fájlokba vagy DVD for- 
mátumban mentem ki a munkámat. Az így kapott, például 
VCD AVI formátumú fájlok jóval kisebbek és könnyebben 
kezelhetők. Egy órányi digitális mozgókép körülbelül 9 GB 
lemezhelyt foglal, a kimentett film ugyanakkor kényelme- 
sen elfér egyetlen 700 MB-os CD-lemezen. 

Mint látjátok, mes amis, linuxos rendszeretek kiváló eszkö- 
zöket biztosít ahhoz, hogy ti magatok - vagy alkalmazásai- 
tok - sztárokká válhassatok. Olyan jól elbeszélgettünk, 
hogy közben elérkezett a záróra, és borfakasztotta mosolyo- 
tokat nézve úgy látom, sikerült néhány emlékezetes felvé- 
telt készítenetek. Na jó, csak vicceltem. Francois, légy oly 
kedves, töltsd még egyszer újra vendégeink poharát. Lehet, 
hogy érdemes volna megörökítenünk az utókornak a bú- 
csúzó pohárköszöntőt?... A következő alkalomig igyunk 
egymás egészségére, mes amis! A votre santé! Bon appétit! 


Linux Journal 2004. december, 128. szám 


Marcel Gagné (mggagneCsalmar.com) 
Ontarioban, Mississaugában él. Legújabb, 1m- 
már harmadik könyve a Moving to the Linux 
Business Desktop (ISBN 0-131-42192-1, 
Addison-Wesley). A rendszerintegrálással és 
hálózati tanácsadással foglalkozó Salmar 
Consulting, Inc. igazgatója. Hobbipilóta, tudo- 
mányos-fantasztikus írások szerzője, jelenleg 
egy kisebb origami [-Rexen dolgozik. 
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Az átdolgozás joga, avagy a szoftver és a zene 


Vagyoni! Jogi jogosultságok. 
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ármennyire hihetetlennek tűnik is első hallásra, olyasféle, a mű lényegét nem érintő változtatásokat, 

jogi szempontból a szerzői jogi védelmet élvező melyek elengedhetetlenek illetve nyilvánvalóan szüksé- 

művek közül a szoftverek a zeneművekhez állnak gesek. Amennyiben erre nem hajlandó vagy nem képes, 
a legközelebb. Legalábbis, ami az átvétel, átdolgozás, fel- a felhasználó ennek más módon való megvalósításáról 
dolgozás, idézés problematikáját illeti". Ugyanis mindegyik " gondoskodhat". Ehhez kapcsolódik a törvény speciálisan 
alkotásnak van két egymás mellett létező megjelenési for- szoftverekre vonatkoztatott része, ahol a többszörözés és 
mája. A Zene, amit hallunk és a szoftver, amit használunk, fordítás kötelező engedélyeztetése alól mentesítést bizto- 
valamely, a háttérben megbúvó, hétköznapi emberek szá- sít, anennyiben az említett esethez hasonlóan a szoftver 
mára érthetetlen vagy felismerhetetlen dokumentáción működtetéséhez ez szükséges. Valamint érdemes azt is 
nyugszik. Ahogy csak szavakat értünk egy forráskódból, megjegyezni, hogy harmadik személyek , beavatkozását" 
a gépi kódból pedig azt sem, ugyanúgy nehézséget okozhat  - ezen lényegi részt nem érintő változtatás eszközölése 


meglátni vagyis inkább , kihallani" kedvenc dallamunkataz céljából — abban az esetben is lehetővé teszi, ha ezt előtte 
öt vonal közé préselt hangjegyekből. Míg a képzőművészeti a szerzőtől nem is kérték. 
alkotás maga a mű, az irodalmi pedig adott esetben maga 


a könyv, addig a zenéhez és a szoftverekhez valamilyen Az ami, majdnem az, ami... 

közvetítő közegre van szükség. Legyen az egy vonós- A , 41" kicsit kakukktojás részlet, ugyanis szintén ezen 

vagy egy Pentium négyes. a ponton kívánom tárgyalni a jogos felhasználásnak a sza- 
bad felhasználás körébe tartozó részleteit, azaz az idézést, 

Alapok és átvételt". 


Az átdolgozás jogát a magyar törvények , 3-1" lényeges he-  Átdolgozás esetében egy alapul szolgáló mű mellett egy 
lyen szabályozzák. A törvény 4. § (1) bekezdésében rendelke- származékos mű is megjelenik. Az pedig, hogy valóban 
zik az eredeti mű szerzőjének azon jogosultságáról hogyaz átdolgozásról, vagy egy -— az eredetitől független — egyéni 
ő jogait az átdolgozás, feldolgozás, fordítások készítése eseté- " eredeti alkotásról van-e szó, a két mű között fellelhető 


ben is tiszteletben kell tartani, ugyanakkor kimondja, hogy kapcsolat léte és mélysége alapján döntendő el. A mérle- 
az említett módokon keletkezett szerzői mű szintén jogosult  gelés mindannyiszor egyedi eset, és szakértő rendelése 
a védelemre, amennyiben egyéni eredeti vonásokat hordoz. —— mellett történik. Csupán az a körülmény, hogy bizonyos 
A második pont a felhasználási engedélyek pontja, mely elemek mindkét alkotásban - akár visszatérően — megje- 
szerint ez a felhasználási szerződés (licenc) keretében sza- lennek, nem alapozza meg az átdolgozás tényének meg- 
bályozott jogosultság kizárólagosan a szerzőtől nyerhető el,  állapíthatóságát. Ahogy a zenében annak az esélye, 

a mű bármilyen formában történő felhasználására?, ugyan- hogy két zeneszerző egymástól függetlenül pontosan 


akkor külön nyomatékosító szabályként kiemeli atörvény,  — ugyanazt a dallamot találja ki, majdnem olyan kicsi, 
hogy az átdolgozás csak kifejezett kikötés esetében tekint- mint hogy egy adott probléma megoldására két progra- 


hető a felhasználási szerződés részéneki. mozó ugyanazt a forráskódú programot hozza létre. 

A harmadik kategóriát a személyiségi jogokat is érintő Azonban az azonos dallam kitalálás esélye nő, ha a tizen- 
integritásvédelemf jelenti, melynek ellenpólusaként a fel- " két fokú komponálás alapelveit követve hozzák létre. 
használót védő rendelkezés áll, mely szerint — amennyi- Ahogy szoftver esetében bizonyos irányvonalat ad már 
ben a szerző hozzájárulását adja a mű felhasználásához, magának a programnak, hogy melyik programozási 


köteles azt , felhasználhatóvá tenni", azaz elvégezni rajta — nyelvet választja a szerző alapul. 


- 


Az elemzés támpontja Gyenge Anikó: Zeneművek átdolgozása a szerzői jogban c. tanulmánya in: Iparjogvédelmi és szerzői jogi szemle 2003/10. 
http:/www.hpo.hu/ipsz/200206/zenemuvek.htm 2003. december 21. 9:00 
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Részlet kérdések 

lovábbi nevesített, ám ki nem fejtett fogalmakat rejt a tör- 
vény, mikor szintén szerzői jogosultságokat rendel azon 
személy részére, aki a művel kapcsolatosan az átdolgozáson 
túl, feldolgozással vagy fordítással nyújt egyéni, eredeti tel- 
jesítményt. Szoftverek és zeneművek esetében sem lehet 
igazán értelmezni a fordítás fogalmát. Kifejezetten fordítás- 
nak ugyanis egyik értelemben sincsen helye, hiszen a zene 
minden nyelven beszél, a szoftverek esetében pedig a fordí- 
tás alatt azt az elengedhetetlen folyamatot értjük, mikor 

a forráskódból gépi kódot készítünk, ezen eljárás pedig 
mentes minden egyéni, eredeti jellegtől, hiszen egy másik 
(fordítóprogram készíti el számunkra a megkívánt formát. 
Így hát a következőkben tárgyalt alapfogalmak két fő kate- 
góriába sorolhatók, egyrészt a jogszerű, a szerző által enge- 
délyezett (bizonyos esetekben ezt meg sem kívánó) átvétel, 
másrészt a műnek illetve egy részletének másik műben való 
jogszerűtlen megjelenése. 

Hasonló tulajdonsága a zenének és a szoftvernek, hogy 

az átdolgozása csak műfajon belül valósul meg. Előfordul- 
nak persze extrém esetek, mikor valaki megfest egy szimfó- 
niát vagy egy extrém tárlaton bemutat egy gépi kódokból 
álló képet. Valamivel gyakoribb az, mikor egy zeneműhöz 
utólagosan készül szöveg, ám ezeket az eseteket leszámít- 
va ezen műfajtákra nem jellemző az átdolgozásokkal elér- 
hető műfajváltás, ahogy például egy filmből regény vagy 
regényből film lesz. 

A feldolgozás fogalmának tisztázásánál azt a halvány elvá- 
lasztó vonalat kell megtalálnunk, melyet voltaképpen a sza- 
bályozásnál maga a törvény sem követ szisztematikusan, 
hiszen az átdolgozásra vonatkozó szabályok alkalmazását 
rendeli a feldolgozások tekintetében is. 

Amennyiben nem adjuk fel a kutatást a konkrét elhatárolási 
pontokat illetően, egy 1973-ból származó (bár a szoftverek- 
ről még tudomást sem vevő) szerzői jogi kézikönyvében ta- 
lálhatunk némi eligazítást". 

Az átdolgozás mindig egy műfajon belüli beavatkozás." 
Míg a feldolgozott művek általában elhagyják eredeti cí- 
müket és műfajukat, de megtartják az eredeti legjellegze- 
tesebb tartalmi és gondolati egységét. Ami azonban a je- 
lenlegi szabályozást illeti, a fent nevezett éles elhatárolás 
félrevezető lehet, hiszen , a törvényi felsorolás azt tükrö- 
zi, hogy az átdolgozásnak és az eredetiséget el nem érő, 

de ahhoz hasonló formai változtatásoknak a különböző 
műfajokban, a gyakorlatban sokféle elnevezése alakult ki... 
Ezek használata egyáltalán nem következetes a jogi tar- 
talmat illetően." 

Az elhalványodott egyéni vonás átvétele esetén nem enge- 
dély nélküli többszörözésről, hanem feldolgozásról beszél- 
hetünk. Ha követjük a Zenei irányvonalát" és átdolgozás 
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alatt a javító célú, rendszerint kisebb beavatkozásokat ért- 
jük, akkor ide sorolható a szabad szoftverek alkotásának 
jónéhány lépése, azaz, mikor egy profi programozó egy 
már más által megkezdett, de félbehagyott, vagy nem töké- 
letesen megalkotott programot forráskódsorok beépítésével, 
vagy éppen cseréjével sokkal gördülékenyebben működő- 
vé, hibamentesebbé tesz. 

A zenében feldolgozásnak tekintett rész (mely szerzői jogi 
szemüvegen át továbbra is az átdolgozás részlete) valójá- 
ban egy tágabb kört ölel fel, a lexikxonokban meghatáro- 
zott Zenei alapanyagon végzett átalakító tevékenységek 
összességét. Az arrangement kifejezés (a mű más berende- 
zésű apparátusra való alkalmazása, mint amelyre az ere- 
detileg készült) a szoftverek hardverhez igazításával lehet 
rokonítható, mikor egy asztali gép alkalmazásait egy 
Palmra viszik át, azaz a speciális körülményekhez igazít- 
ják, mindamellett, hogy az eredeti mű teljes mértékben 
felismerhető marad. 

A modernizálás ugyanúgy, ahogy a régi Zene életre keltése, 
megjelenik a szoftverfejlesztésben is, hiszen ahogy a nép- 
dalok szabadon feldolgozhatóak, ugyanúgy az eredeti, még 
Public Domain alatt álló, vagy más okból szabad szoftverek 
forráskódja, megismerhető és feldolgozhatóak. Ugyanakkor 
egyes régebbi programokban feleslegessé vált programré- 
szek elhagyása (tekintettel a technika fejlődésére) lehetsé- 
gessé válik, ám az ilyen kis mértékű változtatás nem engedi 
áttörni a szerzői minőséghez szükséges egyéni, eredeti jel- 
leget sem, ahogy Mahler zenei változtatásai sem nyertek 
átdolgozásként elismerést". 

Hasonlóan problémás úgy a zenében, mint a szoftverben az 
idézés kérdése, hiszen még zenében nem lehet , lábjegyze- 
telni", esetlegesen egyes kottarészletekhez lenne fűzhető, 
hogy az átvétel mely szerző mely művéből való, az a zene 
megszólaltatását követően többé nem válna ismertté, ha- 
csak nem műértő füllel hallgatják. Szoftvereknél hasonló 

a helyzet, hiszen a program futtatása során nem derül már 
ki, hogy a forráskód részletei kihez és milyen mértékben 
köthetőek. Kereskedelmi szoftverek esetében még a szerzők 
feltüntetésére is ritkán kerül sor, hiszen őket általában a for- 
ráskódban őrzik, melyet nem hoznak nyilvánosságra, gon- 
dolhatjuk tehát, ha az eredeti szerzők név feltüntetéshez 
való joga ilyen módon sérül, milyen elbánásban részesül- 
hetnek az idézett művek szerzői. A szerzői jogi törvény idé- 
zésére vonatkozó rendelkezései? sajnálatos módon mindkét 
esetben elenyésznek. 

lermészetesen a szoftvereknek vannak egyéb, , specifikus" 
feldolgozási formái is, ám ezekre a következő számban 
térünk ki. 


Dr. Dudás Ágnes 


A szerzői jog kézikönyve, szerk: Bernárd Aurél, Tímár István, Közgazdasági és Jogi Kiadó, Budapest 1973 


u. , Mahler karmesteri tapasztalataiból és a közönség ízlésének ismeretéből kiindulva Beethoven és Schumann-szimfóniákat is , kijavított" . 
Egyes helyeken a vonósok eredetileg megkívánt kettőzését megszüntetve, másutt éppen előírva, szünetjeleket átírva, staccato-jeleket beillesztve 
,átszínezte" a partitúrákat. A változtatásoknak azonban ugyanúgy oka volt Mahler érzékeny hallása, mint a kor általános zenei ízlése. Az eredeti 
darabokat viszont nem alakította át olyan mértékben, hogy azokon a leghalványabban is Mahler hatása, egyéni-eredeti alkotótevékenysége 
lenne felismerhető, amelynek alapján a műveket átdolgozásoknak kellene tartanunk." Gyenge Anikó: i.m. Zenei feldolgozások a gyakorlatban 
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